Intercepting ram session of child

Denis Huber huber.denis at ...435...
Thu Aug 18 12:19:59 CEST 2016

I have found the error and corrected the source code [1].


The error was, that I used the same Entrypoint for managing my custom 
Rpc_object<Ram_session> and for passing it to the child constructor.

I think, the child constructor created an Rpc_object<Parent>, which is 
managed by the child's Entrypoint. Then the Rpc_object<Parent> called an 
RPC method from my Rpc_object<Ram_session>, which also is managed by 
this Entrypoint. Thus, the Entrypoint blocked on the remote procedure 
call to Rpc_objcet<Ram_session> waiting for itself to finish the call 
from Rpc_object<Ram_session>. The Rpc_object<Ram_session> needs to use 
this Entrypoint, but it was blocked. Thus, it went waiting for the 

Now Rpc_object<Parent> is waiting for Rpc_object<Ram_session> and vice 
vera => deadlock.

Please correct me, if I am wrong :)

Best regards

On 18.08.2016 10:28, Denis Huber wrote:
> Hello Norman,
> thank you for your well-written answer :)
> On 17.08.2016 14:06, Norman Feske wrote:
>> Hi Denis,
>> first, thank you for providing a test case in such a nicely condensed
>> form. It is great for pin-pointing the problem.
>> On 14.08.2016 18:03, Denis Huber wrote:
>>> I tried to adopt this concept for a custom Ram session. I created a very
>>> short test program [1] (Run script in [2]) which creates a custom
>>> Ram_session_component and tries to transfer quota from its environment
>>> to the custom Ram session component. The quota transfer fails with error
>>> code -1, which means the recipient of the transfer is not a valid
>>> session component [3].
>>> I think the problem is, that I have not created a valid capability of
>>> the custom Ram_session_component. What important fact do I miss in my
>>> implementation? I am grateful for every hint you give me :)
>> Core's RAM service does not know the meaning behind the 'ram_special'
>> capability because this capability does refer to an RPC object living
>> inside your component, not inside core. Core can transfer quota only
>> between RAM sessions known to core. It tries to look up a RAM session
>> for the supplied capability argument but cannot find one. In contrast,
>> if you change the transfer-quota line to
>>   log("t: ", env.ram().transfer_quota(ram_impl._parent_ram, 4096));
>> the operation succeeds because 'ram_impl._parent_ram' refers to a RAM
>> session provided by core.
> This means, the Rpc_objects can communicate, if they are managed by the
> same Entrypoint, but not if they are in different Entrypoints. Just out
> of curiosity: Can I delegate a capability from one Entrypoint to another?
>> If you want the child subsystem to deal with multiple RAM sessions (such
>> as 'env.ram()' and a manually created RAM connection), the "non-root"
>> approach can no longer be applied. In order to allow the RAM sessions
>> refer to each other, they need to be provided by the same RAM service.
>> I.e., when creating the child, you will have to equip it with a RAM
>> session of your RAM service as done, for example, by noux. The
>> '_resources.ram' of the child [1] is a locally-provided RAM-session object.
>> Btw, you will encounter a very similar problem with the PD-session
>> argument for the 'Cpu_session::create_thread' operation. When forwarding
>> this RPC call to core, you will need to replace the capability argument
>> supplied by the client (which refers to your virtualized PD session) by
>> the "real" PD capability as known by core.
>> Could this explanation answer your question?
> Thanks, this explanation helped me to solve the initial problem and I
> could also implement the PD and CPU Rpc_objects (without root objects),
> which intercept the child's session methods.
> Now my problem is the following: If I apply your solution and start a
> child with a custom RAM Rpc_object, then the program hangs up on the
> child creation. I have created a simple program [1] (child component
> [2], run script [3]) to demonstrate the error. The output is
> [init -> random] All is fine until now!
> Error: Test execution timed out
> Makefile:261: recipe for target 'run/random' failed
> make: *** [run/random] Error 254
> This demonstrates that all resource-object creations before the child
> object creation passed without errors. But the program hangs up on the
> creation of the child. What could be the error?
> Best regards
> Denis
> [1]
> [2]
> [3]
> ------------------------------------------------------------------------------
> _______________________________________________
> genode-main mailing list
> genode-main at

More information about the users mailing list