Re: strange Bug

Hello,


> We are looking for an instruction at address 0x15c7a8. Things I would
> check now:

> * If the instruction is not in your program (the one in the build
>   directory), is it maybe in another module that gets packed into
>   your bootstrap.elf image? You get a list of the packed modules
>   when you run make E=.. - the binaries should all be in your build
>   directory.

I have found this in moe:
   GC_try_to_collect_inner():
   /src/l4/pkg/boehm_gc/contrib/alloc.c:404
   15c7a8:       e12fff37        blx     r7


> * At the time of the page fault you end up in the kernel debugger.
>   Use 'lp' to see the list of present threads. One of them will be
>   the one that is in the debugger now. It should be one of the
>   L4Re threads (those have names starting with # in the thread list).
>   Which other thread is currently blocking in IPC to the L4Re thread?
>   What is this thread's state (command 't<id>')? At what instruction
>   is the thread stuck? What binary belongs to this thread?

Do u say JDB starts automatically, when the error occurs?
But typing 'lp <ENTER>' in the UART console, doesn't effect anything.
Do i have to add JDB via modules.list or something?


> * Easy stuff: is your program even executing code in its main()
>   function already? How far does the program get before the page
>   fault happens?

Yes, it runs for a while.
There are two L4-Task doing a protocol over IPC. Client sends a message 
and Server answers. Then Client fails, when perparing his next message 
(no ipc-functions involved).


> Btw., are you debugging this on real hardware or in an emulator, such 
> as qemu?

Only on real HW: ARMv7 Cortex A9.
Qemu doesn't work on my Debian. The window stays black.
Maybe i'll try on an other Linux.



Have a nice day!

ba_f