My favorites | Sign in
Project Home Downloads Wiki
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 36: Broken persistence of x86_64 call stack addresses
2 people starred this issue and may be notified of changes. Back to list
Status:  WontFix
Owner:  ----
Closed:  Jan 2013

Sign in to add a comment
Reported by, Nov 3, 2011
The seems to be a persistence issue with x86_64 call stack addresses. I debugged the issue far enough to know that the correct addresses were passed to plcrash_writer_pack and to know that the wrong addresses came out of plcrash__crash_report__unpack. Interestingly, however, is that only the addresses of my framework are broken. System-addresses seem to work okay.

Here's an example of addresses passed into the writer:

140735438450014,       1   libobjc.A.dylib
140735444500666,       2   CoreFoundation 
140735444500548,       3   CoreFoundation 
4294976942,            4   Ulysses        
140735433280994,       5   Foundation     
140735444143626,       6   CoreFoundation 
140735433199767,       7   Foundation     
140735620579632,       8   AppKit         
140735620366987,       9   AppKit         

And this is read from the binary file:


See that the third address is different. I notice there is a constant offset of 0x2C9E000 between the original address and the one returned. My *guess* is a encoding problem for some numbers. I tried to dig into it but failed due to lack of time and technical details.

It would be pure amazing if you had a look into this. This issue has a somewhat high priority for us!
Nov 3, 2011
Addition: the constant offset of 0x2C9E000 is the same across ALL of the addresses in my binary...
Nov 3, 2011
In addition, Binary Image UUIDs don't seem to be reported correctly. I didn't not yet dive into it enough though to give any details. Here's the reported UUID:


however it should rather be this one:


Thanks again,
Jan 4, 2013
Project Member #3
I had trouble reproducing this behavior way back when.

I finally got around to writing unit tests for all the encoder/decoder functions for primitive types provided by protobuf-c, but was not able to reproduce any failures. I added an additional test for round-trip encoding+decoding of your 4294976942 example above, and it passed.

Unfortunately, I have to close as "Can't Reproduce"
Status: WontFix
Sign in to add a comment

Powered by Google Project Hosting