Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spurious BusFault when trying to start large app #3927

Open
ofabel opened this issue Oct 1, 2024 · 6 comments
Open

Spurious BusFault when trying to start large app #3927

ofabel opened this issue Oct 1, 2024 · 6 comments
Labels
Core+Services HAL, furi & core system services Triage Issues under initial investigation

Comments

@ofabel
Copy link

ofabel commented Oct 1, 2024

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 😢

Target

No response

Logs

No response

Anything else?

  • What does the BusFault mean? Is this due to memory fragmentation?
  • How can I help to debug or even fix this issue?
@hedger
Copy link
Member

hedger commented Oct 1, 2024

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.

@hedger hedger added Core+Services HAL, furi & core system services Triage Issues under initial investigation labels Oct 1, 2024
@ofabel
Copy link
Author

ofabel commented Oct 1, 2024

@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
Copy link
Member

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
Copy link
Contributor

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
Copy link
Member

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
Copy link

biz131 commented Oct 8, 2024

I am having the same issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Core+Services HAL, furi & core system services Triage Issues under initial investigation
Projects
None yet
Development

No branches or pull requests

5 participants