05-02-2013 04:56 PM
I have a simple Cascades application that starts a thread (other than the main thread) and this thread sleeps for 1 second then outputs a message to a TextArea control on the GUI. My application was compiled with -g. If I interrupt the application in gdb I don't see a stack trace of my thread while it's blocked in sleep(). Likewise, if there are other threads in my process that are blocked on any system calls then gdb cannot retrieve their stack traces. The only case were I can get a stack trace is in threads that are not blocked in system calls.
The libraries that are shipped with the NDK are all stripped so there are no symbol information. Also, it's difficult to match the NDK version with what's on the device.
Any help is greatly appreciated.
Solved! Go to Solution.
05-06-2013 12:47 PM
Yes, I experience this difficulty too. It's especially hard when I have an assert(x); and the stack is meaningless. Any suggestions? Is there a gdb stack history command we can use?
09-11-2013 05:49 PM
The latest SDK 10.2 has addressed this problem. The IDE downloads the unstripped binaries that matches the device you are debugging on. These binaries are not stripped and allow for a good stack trace.