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 ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ genode-main mailing list genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main