C crashing .. on intensive task

SDK Development Discussion
1

Hi, does the engine crash on an intensive task? (like one that drops the fps to less than 10)
The crashlog lr/pr don't seem to point to any function within my code. I'm suspecting then that the hogging code is causing the crash.

2

There's a ten second watchdog timer that'll reset the device if you block the run loop for 10 seconds, but it sounds like you're not getting anywhere near that.

If you haven't seen it, the firmware_symbolizer.py python script in the bin folder in the SDK can look up firmware addresses for user space functions in the symbols.db database. Or if you want to post the crashlog.txt file here I can take a look

3

Hi.

I tried this:

arm-none-eabi-addr2line -f -i -p -e ./hyperion_DEVICE.elf 0x90005486 0x90005483

And I got this output:

?? ??:0
?? ??:0

Here are a couple crashlogs. Thanks!

--- crash at 2024/10/09 09:53:13---
build:216ce27b-2.5.0-release.169289-buildbot
r0:00000000 r1:00000001 r2:00000001 r3: 00000000
r12:ffffffff lr:90005483 pc:90005486 psr: 61000000
cfsr:00000082 hfsr:00000000 mmfar:00000000 bfar: 00000000
rcccsr:00000000
heap allocated: 679008
Lua totalbytes=0 GCdebt=0 GCestimate=0 stacksize=0

--- crash at 2024/10/09 09:53:13---
build:216ce27b-2.5.0-release.169289-buildbot
r0:00000000 r1:00000001 r2:00000001 r3: 00000000
r12:ffffffff lr:90005483 pc:90005486 psr: 61000000
cfsr:00000082 hfsr:00000000 mmfar:00000000 bfar: 00000000
rcccsr:00000000
heap allocated: 679008
Lua totalbytes=0 GCdebt=0 GCestimate=0 stacksize=0

--- crash at 2024/10/10 08:39:03---
build:216ce27b-2.5.0-release.169289-buildbot
r0:00000000 r1:00000000 r2:00000000 r3: 00000000
r12:9002fbe7 lr:9000d125 pc:9000c278 psr: 610e0000
cfsr:00000082 hfsr:00000000 mmfar:00000074 bfar: 00000074
rcccsr:00000000
heap allocated: 504768
Lua totalbytes=0 GCdebt=0 GCestimate=0 stacksize=0

4

The python script just hangs for me.

5

From the crashlog, it's definitely an error in your game -- you seem to be dereferencing a null pointer. On the Simulator this would cause a segfault, but on device it crashes the CPU and causes a full reset.

I believe the correct command for addr2line is

arm-none-eabi-addr2line -f -i -p -e ./hyperion_DEVICE.elf 0x00005486 0x00005483

since the ELF created by the compiler is relocatable.

3 Likes
6

Yes. I need to hunt down those pointers. I'm failing with address sanitizer. Thanks!

7

I always forget that we now compile pdex.elf to start address 0 then translate the addresses. Thanks for noting that, Scratchminer! Another useful thing to look at in the crash report (probably why SM noted that it looks like a null pointer dereference) is the CFSR register.

Your CFSR value of 0x00000082 has the DACCVIOL data access violation bit set, meaning you're trying to access invalid memory, and also the MMARVALID (MMFAR register valid) bit, which means the value in the MMAR register is the location of the invalid memory you were trying to access. Handy! In the first two crash logs, that's zero--i.e., you're dereferencing a null pointer. The last has MMAR=0x00000074 (=116 decimal) which happens if you do something like this:

struct mystruct
{
    int a;
    <112 bytes of other stuff>
    int z;
};

int getZ(struct mystruct* ptr)
{
    return ptr->z;
}

and pass a NULL pointer to getZ().

3 Likes