Issue details

While some detailed build configuration, There are potential stack overflow in thread function named main

In this line, main allows 1024 stack size.

However, after checking the stack using our internally developed tool, it might have 1464 Bytes in with some detailed configurations.

Steps to produce

**1. In cc.scons, Add this line:

In 38 line..

"-fstack-usage"

This will help you automatically calculating stack size of each function.

2. Build flipperzero-firmware normally, using this configurations:

./fbt

Now we can get stack usage file (*.su) for each source file, So we can manually check stack size of each function.

In case of main :

There are large call stack with this flow:

main (main) ⇒ 8 bytes
flipper_boot_update_exec (flipper_boot_update_exec) ⇒ 24 bytes
flipper_update_process_manifest (flipper_update_process_manifest) ⇒ 920 bytes
update_manifest_init_mem (update_manifest_init_mem) ⇒ 24 bytes
update_manifest_init_from_ff.isra (update_manifest_init_from_ff.isra.0) ⇒ 16 bytes
flipper_format_read_header (flipper_format_read_header) ⇒ 16 bytes
flipper_format_read_string (flipper_format_read_string) ⇒ 16 bytes
flipper_format_stream_read_value_line (flipper_format_stream_read_value_line) ⇒ 88 bytes
flipper_format_stream_seek_to_key (flipper_format_stream_seek_to_key) ⇒ 88 bytes
stream_eof (stream_eof) ⇒ 8 bytes
__furi_crash_implementation (__furi_crash_implementation) ⇒ 40 bytes
__furi_print_name (__furi_print_name) ⇒ 8 bytes
__furi_put_uint32_as_text (__furi_put_uint32_as_text) ⇒ 24 bytes
furi_log_puts (furi_log_puts) ⇒ 8 bytes
furi_log_tx (furi_log_tx) ⇒ 24 bytes
furi_mutex_acquire (furi_mutex_acquire) ⇒ 16 bytes
xQueueTakeMutexRecursive (xQueueTakeMutexRecursive) ⇒ 16 bytes
xQueueSemaphoreTake (xQueueSemaphoreTake) ⇒ 40 bytes
xTaskResumeAll (xTaskResumeAll) ⇒ 40 bytes
xTaskIncrementTick (xTaskIncrementTick) ⇒ 40 bytes

SUM ⇒ 1464 bytes
So, there are potentially occur stack overflow in main function.

Environment

Version
Commit ad2a800