Hello,
I'm trying to track down a bug in my program; I have a line
>> myconfig->pub.publish((msg_t) &p);
where if I comment it out the program runs (working abnormally of course because data isn't getting out). However, if it's uncommented, I get a bus fault:
$4 = {CPUID = 0x410fc241, ICSR = 0x440f803, VTOR = 0x0, AIRCR = 0xfa050300, SCR = 0x0, CCR = 0x200, SHPR = {0x0, 0x10000000, 0x80000000}, SHCSR = 0x0, CFSR = 0x8200, HFSR = 0x40000000, DFSR = 0x9, MMFAR = 0xffffffff,
BFAR = 0xffffffff, AFSR = 0x0, PFR = {0x30, 0x200}, DFR = 0x100000, ADR = 0x0, MMFR = {0x100030, 0x0, 0x1000000, 0x0}, SAR = {0x1101110, 0x2112000, 0x21232231, 0x1111131, 0x1310132}, unused1 = {0x0, 0x0, 0x0, 0x0, 0x0}, CPACR = 0x0}
obviously -1 is an invalid address, but I don't get a useful PC to isolate where I'm doing this. The stack trace isn't useful:
(gdb) bt
#0 _unhandled_exception () at ChibiOS/os/ports/GCC/ARMCMx/STM32F3xx/vectors.c:208
#1 <signal handler called>
#2 0x55555554 in ?? ()
Putting a breakpoint on that line that seems to be so crucial doesn't help either - it must be optimised somehow.
Any thoughts?
Finding the faulting PC
Moderator: RoccoMarco
- Giovanni
- Site Admin
- Posts: 14891
- Joined: Wed May 27, 2009 8:48 am
- Has thanked: 1202 times
- Been thanked: 996 times
Re: Finding the faulting PC
Hi,
Try compile the SW with no optimizations (-O0) then place a breakpoint on that line. Assuming you didn't do that already of course.
Giovanni
Try compile the SW with no optimizations (-O0) then place a breakpoint on that line. Assuming you didn't do that already of course.
Giovanni
Re: Finding the faulting PC
I did that.
I found this from FreeRTOS:
http://www.freertos.org/Debugging-Hard- ... llers.html
so I put that debugging code into _unhandled_exception.
Now I'm struggling with the idea that the current thread can change while singlestepping:
I found this from FreeRTOS:
http://www.freertos.org/Debugging-Hard- ... llers.html
so I put that debugging code into _unhandled_exception.
Now I'm struggling with the idea that the current thread can change while singlestepping:
Code: Select all
Breakpoint 1, Republisher::RepublisherThread (arg=0x200017a8) at republisher.cpp:17
17 chibios_rt::BaseThread::unlockMutex();
(gdb) display rlist.r_current
1: rlist.r_current = (Thread *) 0x20001948
(gdb) step
chibios_rt::BaseThread::unlockMutex () at ChibiOS/os/various/cpp_wrappers/ch.cpp:382
382 chMtxUnlock();
1: rlist.r_current = (Thread *) 0x20001948
(gdb)
chMtxUnlock () at ChibiOS/os/kernel/src/chmtx.c:251
251 Thread *ctp = currp;
1: rlist.r_current = (Thread *) 0x20001800
Re: Finding the faulting PC
ok, after a lot of singlestepping, that turned out to be a very subtle stacksmash. i feel so stupid now.