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