Handling division-by-zero

[mx at ...19...]

Hi all,

I'm working with Genode 10.05 on top of the OKL4 Microkernel. Recently, my
application raised a division-by-zero. Shame on me - but I was very astonished
when I found out that the root task (core) handles this error rather by chance
than explicitly, for there's no real handler registered.

The error ipc the kernel sends to core, arrives in the sleep_forever function
within core's main thread which sleeps in an ipc call expected never to return.
On the division-by-zero, this ipc returns indeed, causing the ipc_client to
indicate that its receive buffer be too small for the incoming message
(containing the kernel-saved thread context). Upon that, core's main thread
acknowledges the ipc to the kernel and performs the sleep_forever action again.
The offending application thread is aborted by the kernel.

One might call that a proper handling, in fact, it's correct, but it would have
been very nice to have a real handler inside of core giving a simple hint on the
error. The current implementation makes it very hard to debug such errors (In
fact, I had to debug into core to see where the 'copy_utcb_to_msgbuf' failed,
then into the kernel itself to see what was actually signalled to core and then
finally into my application's threads upon the very faint idea what to look
for).

Furthermore, if the message buffer inside of core would have been big enough to
take the kernel's ipc, even the initial 'hint' where to start debugging would
have been missing ;)

Could you please make core at least a little more verbose at this point?

By the way I found out that the handler for an invalid-opcode is missing as
well, but I don't know if there's a chance to catch those errors inside the root
task, for they cause the kernel itself to enter the kernel debugger and hence
halting the system (so rather an OKL4 issue).

Regards


Sven
 
--
Sven Fülster
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20100805/7fd4d448/attachment.html>