• 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: Shark is losing source code (ftn ptr?)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Shark is losing source code (ftn ptr?)


  • Subject: Re: Shark is losing source code (ftn ptr?)
  • From: Rick Altherr <email@hidden>
  • Date: Fri, 6 Jun 2008 12:30:29 -0700


On Jun 6, 2008, at 12:17 PM, kwiley wrote:

I have made a discovery, although I am not sure if it is absolutely consistent with the behavior I am observing. Observing the profile in Shark's tree view, such that I can view the call stack from 'start' all the way down, it appears as if Shark finds source code all the way down a call stack until a function pointer call, i.e., a stack frame allocated not from a typical static function call, but from a function pointer determined, obviously, at runtime. The next level after the function pointer, and all other levels all the way down, suffer the problem I have described -- Shark shows no source for those frames.

Any thoughts on this?

________________________________________________________________________
Keith Wiley    email@hidden   http://www.cs.unm.edu/~kwiley

"Never underestimate a computer program's ability to enter a loop that
counts to a quadrillion.  Furthermore, never underestimate a
programmer's ability to accidentally put a print out statement inside
that loop."
                                          --  Keith Wiley
________________________________________________________________________




_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
@apple.com


This email sent to email@hidden


If we have a callstack for it, the indirect function call isn't likely to be a problem. If the call is into a bundle that is dynamically loaded, that could cause some problems. However, in that case, we won't know the symbol name for the function either. If we have a name for it, we know what library it came from and we are trying to find source info for it. I'm betting this is more likely to be the .a bug coupled with not stripping the debug info from the main executable after making a dSYM.

--
Rick Altherr
Architecture and Performance Group
email@hidden


Attachment: smime.p7s
Description: S/MIME cryptographic signature

 _______________________________________________
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: 
 >Shark is losing source code (From: kwiley <email@hidden>)
 >Re: Shark is losing source code (From: Rick Altherr <email@hidden>)
 >Re: Shark is losing source code (From: kwiley <email@hidden>)
 >Re: Shark is losing source code (From: Jim Ingham <email@hidden>)
 >Re: Shark is losing source code (ftn ptr?) (From: kwiley <email@hidden>)

  • Prev by Date: Re: Shark is losing source code
  • Next by Date: Forcing NSImageView display update
  • Previous by thread: Re: Shark is losing source code (ftn ptr?)
  • Next by thread: Leopard -> GTK+
  • Index(es):
    • Date
    • Thread