strange Bug
ba_f
ba_f at rbg.informatik.tu-darmstadt.de
Sat Nov 22 15:37:01 CET 2014
Hello,
well i guess we're stuck here.
Because i can't find no 15c7a8 nor e12fff37 in myClient.
I also checked the one shared lib myClient uses, without success.
Maybe i do objdump the wrong files?
arm-linux-gnueabihf-objdump -Dlx
l4re-snapshot-2014022818/obj/l4/arm-ca/bin/arm_armv7a/l4f/myClient |
less
arm-linux-gnueabihf-objdump -Dlx
l4re-snapshot-2014022818/obj/l4/arm-ca/lib/arm_armv7a/l4f/libClient.so |
less
But hey, JDB tells me that at 15c7a8 there is the instruction e12fff37
<=> blx r7.
And this is exactly what i get when objdump moe. PC and opcode match.
objdump -Dlx
l4re-snapshot-2014022818/obj/l4/arm-ca/bin/arm_armv7a/l4f/moe | less
GC_try_to_collect_inner():
l4re-snapshot-2014022818/src/l4/pkg/boehm_gc/contrib/alloc.c:404
15c7a8: e12fff37 blx r7
Sounds logic to me, that BOEHM_GC runs into the fault...
>>>> And at 15c7a8 there is e12fff37 <=> blx r7 , which i've
>>>> already found in MOE. But that's not what i'm looking for, is
>>>> it?
>>>
>>> This has nothing to do with MOE. When you objdump the myClient
>>> binary, can you find the address in there? Does the binary
>>> contain blx r7 as well?
>>
>> No, this instruction or PC is not in myClient nor in myServer. But
>> i can find the instruction in a shared lib which myServer uses.
>
> No. We are definitely looking at myClient as this is where the page
> fault happens. Please objdump myClient and find the page fault PC
> again.
Thanks.
More information about the l4-hackers
mailing list