Re: Diagnosing corrupted stacks
Re: Diagnosing corrupted stacks
- Subject: Re: Diagnosing corrupted stacks
- From: John Engelhart <email@hidden>
- Date: Thu, 30 Apr 2009 02:18:27 -0400
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.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden