Hi Johannes, > I implemented this but when I try to attach the dataspace I get a > segfault. I though this might be related to a wrong physical address for > the file but the backtrace leaves me completely clueless. > > >> #0 pseudo_end () at >> /media/sf_kernel/genode/repos/base-linux/src/lib/syscall/spec/x86_64/lx_syscall.S:29 >> #1 0x000000000109d7c1 in lx_futex (val=0, op=0, uaddr=<optimized out>) at >> /media/sf_kernel/genode/repos/base-linux/src/lib/syscall/linux_syscalls.h:350 >> #2 thread_stop_myself () at >> /media/sf_kernel/genode/repos/base-linux/src/include/base/internal/lock_helper.h:66 >> #3 Genode::Cancelable_lock::lock (this=this@entry=0x80ffae0) at >> /media/sf_kernel/genode/repos/base/src/lib/base/lock.cc:123 >> #4 0x00000000010b19c8 in Genode::Lock::lock (this=<optimized out>) at >> /media/sf_kernel/genode/repos/base/include/base/lock.h:33 >> #5 Genode::sleep_forever () at >> /media/sf_kernel/genode/repos/base/src/lib/base/sleep.cc:21 >> #6 0x0000000001065eb8 in Genode::Signal_receiver::block_for_signal >> (this=this@entry=0x64b4a70 <Genode::bootstrap_component()::startup+3472>) >> at /media/sf_kernel/genode/repos/base/src/core/signal_receiver.cc:49 >> #7 0x0000000001096a70 in Genode::Entrypoint::_process_incoming_signals >> (this=this@entry=0x64b3e40 <Genode::bootstrap_component()::startup+352>) >> at /media/sf_kernel/genode/repos/base/src/lib/base/entrypoint.cc:108 >> #8 0x000000000109772e in Genode::Entrypoint::Entrypoint (this=0x64b3e40 >> <Genode::bootstrap_component()::startup+352>, env=...) >> at /media/sf_kernel/genode/repos/base/src/lib/base/entrypoint.cc:329 >> #9 0x00000000010915ac in Genode::Startup::Startup (this=0x64b3ce0 >> <Genode::bootstrap_component()::startup>) >> at /media/sf_kernel/genode/repos/base/src/lib/base/component.cc:244 >> #10 Genode::bootstrap_component () at >> /media/sf_kernel/genode/repos/base/src/lib/base/component.cc:259 >> #11 0x00000000010cd016 in _main () at >> /media/sf_kernel/genode/repos/base/src/lib/startup/_main.cc:248 >> #12 0x0000000000000000 in ?? ()
are you sure that this is the backtrace of the faulting thread? It doesn't look like it. To double-check, have you had a close look at the instruction pointer within the faulting binary as reported by the kernel's dmesg output? As another question, did you first try to hand out an FD for a regular file as I suggested in my last email? Just to rule out potential problems with the FD obtained from your kernel module. The 'rm.attach' - when executed on Linux - is just a process-local operation. It comes down to an invocation of 'mmap' in 'region_map_mmap.cc'. Maybe it helps to instrument the code there? For instrumentation at such a low level, I recommend using the 'raw' function instead of 'log'. The 'raw' function directs the output directly to the kernel - not to core's LOG service. You won't see the component's name as log-message prefix, but rule out any interaction with core by the instrumentation. 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 ------------------------------------------------------------------------------ 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
