Re: Instruments, how to fix leak in C Lib
Re: Instruments, how to fix leak in C Lib
- Subject: Re: Instruments, how to fix leak in C Lib
- From: Wade Tregaskis <email@hidden>
- Date: Wed, 02 May 2012 10:55:45 -0700
> Bytes Used # Leaks Symbol Name
> 84.81 KB 100.0% 48 PQgetResult
> 84.81 KB 100.0% 48 pqParseInput3
> 80.00 KB 94.3% 40 pqResultAlloc
> 80.00 KB 94.3% 40 malloc
> 4.00 KB 4.7% 4 pqAddTuple
> 4.00 KB 4.7% 4 malloc
> 832 Bytes 0.9% 4 PQmakeEmptyPGresult
> 832 Bytes 0.9% 4 malloc
>
> I thought that inside PQgetResult there ought to be a call to pqParseInput3, inside of which I would then e.g. find a call to pqResultAlloc. But this is not the case. So I thought maybe the compiled version of the C-library I am using here does not match the sourcecode I obtained. I recompiled the library from source, built the Objective-C framework and rebuilt my app and did a new trace, but the leaks' trees were identical also now that I excluded the source for error of there being a difference in version.
Symbolication picks the first known symbol before the address in question. It's the consequence of a tragic design flaw in debug info formats to date.
It's more obvious when this goes wrong in Crash Reporter or Shark where you can see the offsets (e.g. "CGContextLock + 38623824").
It happens as a result of stripping of debug info from the built library. This is normal practice for release distributions. That you see it when you build from source yourself implies that you either didn't actually get your new version of the library loaded as expected, you didn't build it with full debug info to begin with, or that at some point some of the info was stripped again.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden