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