My favorites | Sign in
Project Home Downloads Wiki
New issue   Search
for
  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 maxseele...@googlemail.com, 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:

140735438450014
140735444500666
140735444500548
4341761454     
140735433280994
140735444143626
140735433199767
140735620579632
140735620366987

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
#1 maxseele...@googlemail.com
Addition: the constant offset of 0x2C9E000 is the same across ALL of the addresses in my binary...
Nov 3, 2011
#2 maxseele...@googlemail.com
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:

33a598857c2e39368c9c8d51189a52b1

however it should rather be this one:

DBEC2772-4F8D-30F0-AA2D-9D15597DB467

Thanks again,
Max
Jan 4, 2013
Project Member #3 landon.j.fuller@gmail.com
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