can not get ipc error

yuqing wang happymoodmglm at ...9...
Tue Oct 8 10:42:27 CEST 2013

I want to get the IPC error because I want to recover a crashed component.
I have read a paper about trust recovery in L4RE,I just want to try the
same work on Genode.
I modity the fourth parameter of L4_IPC_CALL ,now I can get a  timeout
error,so I can continue my research.


2013/9/26 Norman Feske <norman.feske at ...1...>

> Hello Yuqing Wang,
> > I used launchpad to start a hello_client and hello_server.I closed
> > hello_server and expected the call from hello_client could  cause an ipc
> > error ,because the target is not exist .
> I cannot give you details about the Fiasco.OC-specific part of your
> question but I welcome the discussion about IPC errors in general.
> Recently, I came to the realization that we should remove the notion of
> IPC errors from the Genode API. Why is that? In general, a client that
> calls a server ultimately has to accept that the call may never return.
> Such a call is similar to calling into any piece of unknown code such as
> a 3rd-party library. For example, the call may never return because the
> server has entered an infinite loop. For the client, it make no
> difference whether the server behaves that way or the server does not
> exist at all.
> In your case, the parent intentionally killed the server process. If the
> client receives an IPC error, it gains the bit of knowledge that the
> server does not exist anymore. But maybe the parent wants to hide the
> fact? When reflecting such a condition in the form of an error code, the
> parent has no means to hide this information from the client.
> Currently, there exists the 'Ipc_error' exception but I cannot come up
> with a use case where the knowledge about an IPC error actually helps
> the client. In current Genode components, this condition remains
> unhandled anyway and lets the client process abort. In the case where a
> server disappears (note that this condition is always mandated by the
> common parent of both client and server), it makes hardly any difference
> whether the client process aborts or simply gets stuck. The parent
> wanted to get its child into trouble - so be it.
> Finally, the conditions for IPC errors are not consistent across the
> Genode base platforms. An IPC error is always some exceptional condition
> but its root cause varies. For example, on Linux, an IPC error occurs
> when the client cannot create a socket pair (e.g., due to a resource
> limit). On OKL4, an IPC error is merely raised during a failed send
> phase of an IPC. On NOVA, IPC errors are never raised in the
> platform-specific code. Because of these differences, platform-agnostic
> code generally cannot draw a meaningful conclusion about handling such
> an IPC error.
> It sounds like you have a valid use case for responding to IPC errors.
> If yes, I would very much appreciate to learn about it.
> Cheers
> Norman
> --
> Dr.-Ing. Norman Feske
> Genode Labs
> ·
> Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
> Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> _______________________________________________
> Genode-main mailing list
> Genode-main at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the users mailing list