I'm using GNUEABI to remote debug an ARM device, I'm able to set breakpoints, step, view memory, etc.
...in general life is good
however when break arbitrarily and then type 'info threads' I do get a list of threads, but the symbols arent resolving
(gdb) info threads 7 Thread 10283 0x402a42a4 in ?? () 6 Thread 10282 0x402a42a4 in ?? () 5 Thread 10281 0x401c9d68 in ?? () 4 Thread 10280 0x401c9d68 in ?? () 3 Thread 10279 0x401cb3f4 in ?? () *2 Thread 10278 0x401cb294 in ?? () 1 Thread 10195 0x0001c5e0 in ?? ()
if I were to set a breakpoint and then wait for it to hit all threads but the one with the breakpoint would be like the above, but the thread with the breakpoint would resolve
if I try to examine the backtrace of one of these threads, what I see is something like this
(gdb) bt #0 0x003d0f00 in ?? () #1 0x0000027f in ?? () #2 0x00000277 in ?? () #3 0x4360c4e0 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?)
NOTE: I dont think the stack is corrupt, rather I think gdb thinking the stack is corrupt is related to the problem and likely a hint?
ideas? - keep in mind, when a breakpoint hits the call stack looks great.
Do you have a reason to expect those threads to be executing your code? Quite often, threads are running library code or sleeping, and in either case they're not running your code. However, when you set a breakpoint in you code, it's only hit when that thread actually runs your code.
I'd bet you would see some of your code on some stack traces, though. Check it out; it will be enlightening.
User contributions licensed under CC BY-SA 3.0