Logging/printf's in RT env

[Rene Wittmann]

> > > 
> > > printf is usually also a log function.
> > > 
> > > The priorities of the logserver are at 32, so in the first example
> > > they're inbetween and in the latter one completely below.
> > > 
> > > Does the PF go away when you add --prio 210 (or similar) as an argument
> > > to log?
> > > 
> > Yes, it goes away.
> > But I thought that, if you have a real-time application running it will
> > not be influenced by some "time-sharing" application as the logserver
> > should be.
> 
> Well, if you use it... see Martins reply...
>  
OK, so I thought the LOG-Server was exactly the thing I was searching
for, I didn't expect that LOG() uses _synchronous_ IPCs. But that
explains the behaviour. 

As Martin said: it's really slow with logging, so I just have a buffer
storing my results and that works fine for me.

I was using the LOG-functions because they are also used in a RT-example
in your "hello"-package...

> > > Can you send me a backtrace with unstripped binaries when the PF
> > > happens? Thanks.
> > > 
> > Sure, I can if you tell me how to do it...
> > 
> > The exact error message is:
> > 
> > app| L4RM: [PF] write at 0x01306f58, eip 0380e48b, src 9.02
> > app| [9.0] l4rm/lib/src/pagefault.c:78:__unknown_pf():
> > app|  unhandled page fault
> 
> This message alone doesn't help me much as I need to know where in terms
> of source code it happened. The EIP alone is only useful to find the
> position in the binary.
> 

> > So how would one produce a useful backtrace inside fiasco? Or is there a
> > way to use another debugger (gdb?)?
> 
> You can also use 'objdump -ldS app' and post the code around the
> pagefault EIP, so you know where it happens. But a backtrace is useful
> too.
> 
Thanks for your helpful reply: I found the position where the error
resides: in one of my functions (trying to write outside the boundaries 
of my array). The strange thing is that it only occurs on VMware. When I 
use the LOG functions, it slowed down and mixed totally up. 
When testing on real hardware the error didn't occur, even when setting
the periods absurdly small.
So thanks Adam for the hints.
And sorry for bothering you ;-)

Regards,
Rene