• 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: Tom McHale <email@hidden>
  • Date: Fri, 01 May 2009 09:23:34 -0700


On Apr 30, 2009, at 5:42 PM, John Engelhart wrote:

On Thu, Apr 30, 2009 at 5:04 PM, Thomas McHale <email@hidden> wrote:

On Apr 29, 2009, at 11:18 PM, John Engelhart wrote:

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.
Thanks for that John. I see that gets entry/return at the app level. Any idea of how to extend it to the frameworks and so on.

Here's something else you can add.  Again, I'd only recommend this with a ring buffer policy because the amount of data that can be generated can easily overwhelm your system.  Even with a ring buffer, this kind of blanket capture can really slow your system down and can easily spend 80% of it's time in the kernel.  Again, make sure to run /Library/Application\ Support/HWPrefs/CPUPalette.app/ and shut down all CPU's but one to dramatically simplify things.

pid$target:::entry { printf("// %s\n", probemod); ustack(); }
pid$target:::return { printf("// %s\n", probemod); }

objc$target:::entry { printf("// %s\n", probemod); ustack(); }
objc$target:::return { printf("// %s\n", probemod); }

The ustack() 'function' causes dtrace to print a complete stack back trace on entry.  This simplifies having to reconstruct it by hand, but it means more data is logged per entry. 

You are right, that brings my machine to its knees even with a reasonable ring buffer and limiting to one CPU.

What to do? It would be nice to surgically strike the frameworks I am using and do the probes a couple at a time.

- Tom

 _______________________________________________
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

  • Follow-Ups:
    • Re: Diagnosing corrupted stacks
      • From: John Engelhart <email@hidden>
  • Next by Date: Re: Diagnosing corrupted stacks
  • Next by thread: Re: Diagnosing corrupted stacks
  • Index(es):
    • Date
    • Thread