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