Hello Jonhannes,
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.
the problem could very well be related to the process-creation mechanism. All processes are created by forking from core (via clone). Look out for 'lx_create_process'. Dataspaces are normally attached via the 'MAP_SHARED' flag passed to 'mmap'. May it be that the mmap handling of your kernel module somehow misses to consider this flag? (not that I would know how to handle it)
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).
To get a clearer picture, an instrumentation as illustrated in the attached patch can be helpful. The 'wait_for_continue' function waits until the user presses return. By placing it in the process-creation code path, you can probe the state at various points. By printing the return value of 'lx_gettid()' in your messages, you can see who is talking. The 'wait_for_continue' hook also provides you with a convenient way to attach GDB *before* the interesting code parts are executed. By using the 'Genode::raw' function instead of 'Genode::log' for log output, messages go directly to the kernel, not to core's LOG service. So you can instrument lowest-level details (like IPC and process creation) without fearing any deadlocks.
In order to let the key presses reach Genode, you need to change the run script to use 'run_genode_until forever', which puts the expect tool in interactive mode. The attached patch changes the 'run/log.run' script as an example.
The instrumentations with 'wait_for_continue' also allow you to inspect '/proc/<PID>/maps' of core and init at various stages of the process creation. Thereby you can derive the information about the backing store for virtual-address areas. E.g., assuming that a mapping is missing in init (the forked process) right after clone - eventually producing a segmentation fault, you can look into the 'maps' file of core to see the origin (file) of the original mapping at the fault address.
I hope that these debugging hints are of help for your further investigation.
Cheers Norman