On Wed, Apr 29, 2009 at 8:01 PM, Thomas McHale
<email@hidden> wrote:
When the crash happens the app just goes poof and in gdb I don't get any helpful info at all.
Are there more extensive ways to configure gdb to catch stack problems?
Sorry, I should have included this in my first message.... My first post gave a dtrace script that traced everything, the output of which can be huge. If you just want to catch the tail end of something, you can use a ring buffer:
---
#!/usr/bin/dtrace -s
#pragma D option bufpolicy=ring
#pragma D option bufsize=4k
#pragma D option quiet
#pragma D option flowindent
#pragma D option zdefs
pid$target:a.out::entry { printf("\n"); }
pid$target:a.out::return { printf("\n"); }
objc$target:::entry { printf("// %s\n", probemod); }
objc$target:::return { printf("// %s\n", probemod); }
---
You can adjust the bufsize to taste, but 4k should be enough for you to catch the last gasp. Since this script uses a ring buffer, removing the 'a.out' in the pid... line becomes a possibility. This can really slow down execution time, though, since this logs every function call in every library. If you do decide to trace everything this way, you'll probably want to bump the bufsize up to something like 64k.