strange Bug

[Martin Schröder]

Am 22.11.2014 um 15:37 schrieb ba_f:
>
> 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...


Hi ba_f,

blx r7 is a false alarm, it cannot cause this type of write page fault. Even the instruction itself makes no sense since r7 has a 
value of 1.

Could you do the following: Insert a known write page fault into your client (maybe something like *(volatile int *)0x0=0xaffedead; 
) and search for the pc in "objdump -d" on myClient. You can do the same with myServer. This should match and you will see opcode 
causing the write page fault.

Now enter JDB and dump the instruction @pc. This does not match the opcode caused the write page fault. Check the last line of the 
dump screen and you will see the reason: "dump: d<010001fc> physical".


Martin.