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
--
Dr.-Ing. Norman Feske
Genode Labs
https://www.genode-labs.com · https://genode.org
Genode Labs GmbH · Amtsgericht Dresden · HRB 28424 · Sitz Dresden
Geschäftsführer: Dr.-Ing. Norman Feske, Christian Helmuth
diff --git a/repos/base-linux/src/core/native_pd_component.cc b/repos/base-linux/src/core/native_pd_component.cc
index 937a91f..3ef38ba 100644
--- a/repos/base-linux/src/core/native_pd_component.cc
+++ b/repos/base-linux/src/core/native_pd_component.cc
@@ -29,6 +29,7 @@
using namespace Genode;
+extern "C" void wait_for_continue();
/***************
** Utilities **
@@ -171,6 +172,9 @@ void Native_pd_component::_start(Dataspace_component &ds)
Execve_args arg(filename, argv_buf, env,
Capability_space::ipc_cap_data(_pd_session._parent).dst.socket);
+ raw("waiting for key press before lx_create_process...");
+ wait_for_continue();
+
_pid = lx_create_process((int (*)(void *))_exec_child,
stack + STACK_SIZE - sizeof(umword_t), &arg);
diff --git a/repos/base/run/log.run b/repos/base/run/log.run
index 545809a..8c66f1a 100644
--- a/repos/base/run/log.run
+++ b/repos/base/run/log.run
@@ -25,7 +25,7 @@ build_boot_image "core ld.lib.so init test-log"
append qemu_args "-nographic "
append xen_args { sdl="0" }
-run_genode_until "Test done.*\n" 20
+run_genode_until forever
grep_output {\[init -\> test-log}
------------------------------------------------------------------------------
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
