Re: [SOLVED BUT UNEXPLAINED] Framework load address from an exception log
Re: [SOLVED BUT UNEXPLAINED] Framework load address from an exception log
- Subject: Re: [SOLVED BUT UNEXPLAINED] Framework load address from an exception log
- From: Nick Blievers <email@hidden>
- Date: Wed, 13 Mar 2013 17:42:21 -0500
- Acceptlanguage: en-US
- Thread-topic: [SOLVED BUT UNEXPLAINED] Framework load address from an exception log
>
> On 13 Mar 2013, at 1:37 PM, Jerry Krinock wrote:
>> Thanks to Nick Blievers who replied, off-list accidentally, I have an answer for this. We don't understand it, but it works, at least in this case.
>>
>> The part of the call stack that I needed to symbolize is this:
>>
>> 2 CoreFoundation 0x00007fff907c234a -[NSArray arrayByAddingObject:] + 138
>> 3 MyFramework 0x0000000100152704 MyFramework + 614850
>> 4 MyFramework 0x0000000100152cd5 MyFramework + 616339
>> 5 MyFramework 0x00000001000395db MyFramework + 202203
>> 6 Foundation 0x00007fff92f34677 __NSThreadPerformPerform + 225
>>
>> Find at the *lowest* call in MyFramework, line 5 in this case. As Nick pointed out to me,
>>
>> 0x00000001000395db - 202203 = 0x100008000
>>
>> Voila! 0x100008000 is the actual load address of the framework. Simply use this when calculating the address for each line, including line 5, ask gdb for its info, and you get answers that call one another as expected. And at the top lies bug I was looking for.
>>
>> Can anyone explain why this works, and generalize its applicability?
>
>
> Hmm, I thought I knew, but on further examination, I don't.
>
> My guess is that if the symbolizer doesn't find any function names, it uses the first address in the text segment and pretends there's a function named "MyFramework" (or whatever) that starts there. So, line 5 says: the program counter was at 0x00000001000395db, which is 202203 bytes into the "function" named MyFramework.
>
> Equivalently, line 1 says, "I was at address 0x00007fff907c234a, which was 138 bytes into the -arrayByAddingObject: function", so you could compute the slide for CoreFoundation by finding its address for -[NSArray arrayByAddingObject:], adding 138, and subtracting from 0x00007fff907c234a.
>
> However, my theory doesn't explain why lines 3 and 4 don't give the same answer as line 5: they give a slide of 0x1000bc542, which isn't even an integral number of pages. Maybe the fake "MyFramework" symbol is sometimes placed at some internal boundary instead? Is there anything interesting at offset 0xb4542 in MyFramework?
My guess here is that it is giving an offset from the smallest address it knows about. Be that the start of the __TEXT segment, or an exported function (given it is a framework, and presumably, some functions are exported, there must be some function addresses listed in the symbol table).
However, I cannot reproduce this behaviour at all:
0 libsystem_kernel.dylib 0x00007fff8c23782a __kill + 10
1 libsystem_c.dylib 0x00007fff8bea5a9c abort + 177
2 libtest.dylib 0x00000001036ffd77 0x1036fe000 + 7543
3 libtest.dylib 0x00000001036ffd89 0x1036fe000 + 7561
4 libtest.dylib 0x00000001036ffd99 0x1036fe000 + 7577
5 libtest.dylib 0x00000001036ffe0d test_function_crash + 13
6 test 0x00000001036fbec9 main + 57
7 test 0x00000001036fbe84 start + 52
Maybe there is a difference with linking a framework rather than just a library, but I don't think so.
Nick
_______________________________________________
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