Understanding a FATAL ERROR in my application

RE: Understanding a FATAL ERROR in my application

ovrebekk — Wed, 28 Dec 2022 08:51:35 GMT

The map file can often be a useful debugging tool with issues like these. It is simply called zephyr.map, and can be found next to zephyr.hex in the build folder.

RE: Understanding a FATAL ERROR in my application

nategreco — Wed, 28 Dec 2022 03:55:26 GMT

That was my thinking, but I didn't consider looking at the map file to see what would have been overwritten.

RE: Understanding a FATAL ERROR in my application

ovrebekk — Tue, 27 Dec 2022 09:21:54 GMT

Hi Nathan

Is it possible that the buffer overrun started writing into some of the variables used by the LVGL library?

If you look at the map file you should see which variables come after the one that was overrun, which might explain why it failed like it did.

Either way, good to hear you were able to find the root cause.

Best regards
Torbjørn

RE: Understanding a FATAL ERROR in my application

nategreco — Fri, 23 Dec 2022 02:31:17 GMT

It indeed turned out to be buffer overrun, but I don't see why the fault happened in the LVGL library. I'm thinking an area of memory must have been overwritten that was later used by the LVGL library.

RE: Understanding a FATAL ERROR in my application

nategreco — Fri, 23 Dec 2022 02:29:35 GMT

Just an update - I did find a buffer be buffer overrun in a write characteristic callback. In no way was it related to LVGL, so I'm still at a loss with that call stack and why the error was thrown in lv_gc.c?

I will close this ticket now.

RE: Understanding a FATAL ERROR in my application

nategreco — Thu, 22 Dec 2022 12:46:07 GMT

Dissassembly just has a `??` for 0x0003fda5, which I guess makes sense given the instruction address is invalid.

I think the issue might be buffer overrun, I'm going to poke more and share my code if I'm stuck.

RE: Understanding a FATAL ERROR in my application

nategreco — Thu, 22 Dec 2022 12:45:04 GMT

Thanks - I am using LVGL and Bluetooth, but there are no calls to the LVGL library outside of my main thread, so the fact that a Bluetooth RX thread throws an invalid exception on that line does not make any sense.

The issue is definitely in my control point write callback for my FTMS implementation. I think I'm mishandling the copying of the param structure to the response (indication per the standard). I'm going to try process of elimination to isolate the offending line. If I get stuck I'll share my code (it's a bit messy, I don't want to burden someone else reviewing it until I can isolate it better).

I think at the end of it where I'll probably want some clarity is why the debugger was so unhelpful. Seems like maybe it thinks it executing a section of code it shouldn't be?

RE: Understanding a FATAL ERROR in my application

ovrebekk — Thu, 22 Dec 2022 10:16:22 GMT

My guess would be a null pointer issue, caused by a memset call in lv_gc.c (line 42).

If the BT_RX thread is the culprit I assume you are calling some LVGL functions from a Bluetooth callback in your code?

Possibly you are passing an invalid pointer to one of these functions?

In general calling various libraries from callbacks directly can be risky, since callbacks are often running in interrupt context, and it is limited what you can do from interrupts directly. I noticed this myself in the context of trying to combine LVGL and Bluetooth. But in this particular case the issue seems more pointer related.

If you are unable to figure it out, would you be able to share your code?

Best regards
Torbjørn

RE: Understanding a FATAL ERROR in my application

mytzyiay — Thu, 22 Dec 2022 04:30:45 GMT

If I had to guess, I'd say the fault is happening because r15/pc doesn't actually point to instruction memory. Possibly, it was restored from a corrupted stack or thread context struct, or the code jumped to a corrupt function pointer.

What is the code around r14/lr, 0x0003fda5?

Any possibility of a use-after-free or buffer overrun in the application code?