| Hello,
We've been experiencing "random" crashes in our app recently, that were seemingly caused by a stack overflow. Increasing the stack size for one of the threads made the crashes go away. There are about 8 threads running during the whole life of the application. Crashes happened at randoms locations, and most of the time GDB could not display a callstack or just a small part of it. The app would always stop with GDB dislaying this message: - "Program received signal: “EXC_BAD_ACCESS”."
And a combination of these: - "Previous frame inner to this frame (gdb could not unwind past this frame)"
- "Data Formatters temporarily unavailable, will re-try after a 'continue'. (The program being debugged was signaled while in a function called from GDB. GDB remains in the frame where the signal was received. To change this behavior use "set unwindonsignal on" Evaluation of the _expression_ containing the function (dlopen) will be abandoned.)"
- "Data Formatters temporarily unavailable, will re-try after a 'continue'. (Not safe to call dlopen at this time.)"
- "warning: Unable to restore previously selected frame. warning: check_safe_call: could not restore current frame"
From what I understand GDB is telling us that it can't get a proper callstack, supposedly because our app corrupted it. The only thing that made me think of threads stack sizes is when I saw this message: - "No memory available to program now: unsafe to call malloc"
I don't know how these things work behind the scenes, but is there a simple way of diagnosing a stack overflow? Either some debug setting to check in the project properties, or running the app with a particular instruments from Instruments? I compiled everything with -fstack-protector-all but I didn't see any change in behavior. I launched the app with the "Threads" instrument, but wasn't able to find what I was looking for.
A co-worker has been experiencing with signal catching for a day. He's now able to get signals such as SIGBUS or SIGSEGV and the matching thread pid, but it won't work unless the app is run from the terminal (ie it doesn't work while debugging). But still these signals may be received in various situations and we don't know how to exploit them.
Ideally we'd like a system that tells us "this particular thread has reached its stack limit", and a tool that can display this stack's use over time so we can tell if a particular function or code path takes up too much stack memory. Is that possible?
Thanks!
Guillaume
(sorry if this is a duplicate, I sent it 5 hours ago and didn't receive anything back)
|