• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Diagnosing corrupted stacks
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Diagnosing corrupted stacks


  • Subject: Re: Diagnosing corrupted stacks
  • From: John Engelhart <email@hidden>
  • Date: Thu, 30 Apr 2009 02:00:41 -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?

You can give dtrace a whirl.  Something like the following:

---
#!/usr/bin/dtrace -s

#pragma D option bufsize=128m
#pragma D option quiet
#pragma D option flowindent
#pragma D option zdefs

/* a.out is an alias for the loaded command. */
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); }
---

Save it to a file, say 'traceEntry.d'.  In order to vasty simplify things, run "/Library/Application\ Support/HWPrefs/CPUPalette.app/" and turn off all CPUs but one, and then do the following:

shell% sudo dtrace -s traceEntry.d -c EXECUTABLE

The output from this can be... voluminous, to say the least.  You'll get something like this for output:

CPU FUNCTION                                 
  0  -> +load                                 // NSObject
  0  <- +load                                 // NSObject
[ .. snip ..]
  0  -> start                                 
  0    -> main                                
  0      -> +initialize                       // NSObject(NSObject)
  0      <- +initialize                       // NSObject(NSObject)
  0      -> +alloc                            // NSObject
  0        -> +allocWithZone:                 // NSAutoreleasePool

Lines without a C style // comment are regular functions in your executable.

This isn't perfect, but can probably give you and idea of what was going on just before things went really bad.  Hopefully that's enough for you to either "know" what went wrong from context, or let you pick a good spot to set up a break point before things go bad.  If you want the output slightly prettier, you can use something like:

shell% sed 's/[ \t]*\/\// \/\//' dtrace_output > dtrace_pretty

This 'de-tabs' the comments.  objc exceptions will have a tendency to throw off the flow indentation.  If you're not familiar with dtrace, I recommend http://docs.sun.com/app/docs/doc/817-6223 , or http://dlc.sun.com/pdf/817-6223/817-6223.pdf if you prefer your documentation in PDF form.

 _______________________________________________
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

References: 
 >Diagnosing corrupted stacks (From: Thomas McHale <email@hidden>)

  • Prev by Date: Re: Diagnosing corrupted stacks
  • Next by Date: Determine nested return value from asm in debugger
  • Previous by thread: Re: Diagnosing corrupted stacks
  • Next by thread: Re: Diagnosing corrupted stacks
  • Index(es):
    • Date
    • Thread