I have found the error and corrected the source code [1].
[1]
https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/4c02e6c865518cbae0c1648a346cabd0385fe175/src/random/main.cc
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
Entrypoint.
Now Rpc_object<Parent> is waiting for Rpc_object<Ram_session> and vice
vera => deadlock.
Please correct me, if I am wrong :)
Best regards
Denis
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]
> https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/5676b3c5732e01f2dc02fb81082f5c38bd23f86b/src/random/main.cc
>
> [2]
> https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/5676b3c5732e01f2dc02fb81082f5c38bd23f86b/src/sheep_counter/main.cc
>
> [3]
> https://github.com/702nADOS/genode-CheckpointRestore-SharedMemory/blob/5676b3c5732e01f2dc02fb81082f5c38bd23f86b/run/random.run
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> genode-main mailing list
> genode-main@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/genode-main
>
------------------------------------------------------------------------------
_______________________________________________
genode-main mailing list
genode-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/genode-main
