base-linux ram dataspace file descriptor usage

[Johannes Kliemann]

Hi Norman,

> have you tried to add this test directly in '_export_ram_ds' inside
> core. That is, 'mmap'ing it locally, writing 'ds->size' number of bytes,
> reading them again, followed by clearing them. Just to be sure.

Yes I did. I also added such a test in _map_local and in both cases I
could read and write the whole memory.

> RAM dataspaces are used as backing store for any dynamically allocated
> memory. So it is not surprising to see this fault in the heap. The
> segmentation fault in the lock implementation is certainly caused by a
> lock that resides within a dynamically allocated object.

Could this have to do with using a vfork like mechanism instead of fork?
So that the Capability is passed but the mapping doesn't exist any more
for the child?
I could verify that the segmentation fault only appears after clone in
the child.

I was able to create an environment to use gdb. The segfault happens
always in repos/base/src/lib/base/heap.cc:217 which is the begin of bool
Heap::alloc(size_t size, void **out_addr). out_addr had the value of
0x7fffe7ffe018 and when I tried to get a backtrace gdb said that it
cannot access 0x7fffe7ffe008.
Both ranges seem to reside in 0x7fffe7ffe000 which is the return value
of the first lx_mmap after clone (unfortunately I cannot tell if this
happens in the parent or in the child).

> Thread 2.1 "ld.lib.so" received signal SIGSEGV, Segmentation fault.
> 0x00007fffdff47732 in Genode::Heap::alloc (
>     this=0x7fffe00945e0 <Genode::Heap* unmanaged_singleton<Genode::Heap, 8, Genode::Pd_session*, Genode::Region_map*, Genode::Heap::{unnamed type#1}, char (&) [8192], unsigned long>(Genode::Pd_session*&&, Genode::Region_map*&&, Genode::Heap::{unnamed type#1}&&, char (&) [8192], unsigned long&&)::object_space>, size=140, out_addr=0x7fffe7ffe018)
>     at /media/sf_kernel/genode/repos/base/src/lib/base/heap.cc:217
> 217     {
> (gdb) bt
> #0  0x00007fffdff47732 in Genode::Heap::alloc (
>     this=0x7fffe00945e0 <Genode::Heap* unmanaged_singleton<Genode::Heap, 8, Genode::Pd_session*, Genode::Region_map*, Genode::Heap::{unnamed type#1}, char (&) [8192], unsigned long>(Genode::Pd_session*&&, Genode::Region_map*&&, Genode::Heap::{unnamed type#1}&&, char (&) [8192], unsigned long&&)::object_space>, size=140, out_addr=0x7fffe7ffe018)
>     at /media/sf_kernel/genode/repos/base/src/lib/base/heap.cc:217
> Backtrace stopped: Cannot access memory at address 0x7fffe7ffe008

I still cannot tell what happens there but this doesn't seem to be
component specific. I created a config with only a single component that
only prints a single log message and the problem occurs.

I hope this information helps you, and thank you for your help,
Johannes