flipperdevices / flipperzero-firmware

Flipper Zero firmware source code
https://flipperzero.one
GNU General Public License v3.0
12.72k stars 2.7k forks source link

Spurious BusFault when trying to start large app #3927

Open ofabel opened 2 weeks ago

ofabel commented 2 weeks ago

Describe the bug.

When I try to start a large app on the Flipper using the Buttons and the UI, Flipper crashes and reboots with a BusFault with an occurrence of about 80%. When I do the same using the CLI, crashes are much less common (only about 10%). According to top, there is about 33 KB of RAM left when the app is running.

Reproduction

  1. Start a large app (try uPython if you need a test subject).
  2. See Flipper crashing :cry:

Target

No response

Logs

No response

Anything else?

hedger commented 2 weeks ago

Bus fault means invalid memory access. Usually they originate from programming errors.

https://community.st.com/t5/stm32-mcus/how-to-debug-a-hardfault-on-an-arm-cortex-m-stm32/ta-p/672235#toc-hId--858929380

Please provide a minimal sample code with correct API usage and overall programming that leads to a BusFault for further investigation.

ofabel commented 2 weeks ago

@hedger while I was on the hunt for bugs in the application, I discovered the following log output:

57616 [I][Loader] Loading /ext/apps/Tools/upython.fap
57794 [E][Elf] Not enough memory to load section data
57797 [E][Elf] Error loading section '.rodata'
57800 [E][Elf] Not enough memory
57802 [E][Loader] Status [3]: Preload failed, /ext/apps/Tools/upython.fap: Not enough memory

This log message always occurs right before the bus fault. I also added a furi_delay_ms(1000) as a first statement in the entry point function. So when the program successfully starts, it will do nothing for 1 sec. So I can tell if the bus fault happens after the delay or before. It happens before.

I also tried to create a similar large application by generating random nonsense C code with Python. The resulting binary is as large as the uPython application but it doesn't crash. I think this issue has something to do with how the memory segments are arranged in the binary and how they are loaded into the RAM.

doomwastaken commented 2 weeks ago

We have several bugs in backlog that go down to having not enough memory to start and app and additional memory consuming things running in background.

Having active RPC session might have an affect, such as connection to qFlipper or sync to mobile app

CookiePLMonster commented 2 weeks ago

Bus fault means invalid memory access. Usually they originate from programming errors.

FWIW, unrelated, but the issue of Subghz causing an OOM with qFlipper + VGM running has a 50/50 chance of either failing with "out of memory" or BusFault. It seems possible that there is something in the allocator code that can result in a BusFault in out-of-memory scenarios.

doomwastaken commented 2 weeks ago

Yeah, pretty sure we have this case in backlog, I will re-check. I believe we should offer to reboot flipper in out of memory scenario

biz131 commented 1 week ago

I am having the same issue.