Hello,
On Tue, Sep 14, 2010 at 09:45:10AM +0200, stephane frenot wrote:
(gdb) info thread
- 1 process 2370 pseudo_end () at
/opt/genode/genode-r121/base-linux/../base-linux/src/platform/x86_64/lx_syscall.S:29
(gdb) info stack #0 pseudo_end () at /opt/genode/genode-r121/base-linux/../base-linux/src/platform/x86_64/lx_syscall.S:29 #1 0x0000000001021442 in lx_nanosleep (this=0x103c400) at /opt/genode/genode-r121/base-linux/src/platform/linux_syscalls.h:371 #2 thread_stop_myself (this=0x103c400) at /opt/genode/genode-r121/base-linux/src/base/lock/lock_helper.h:70 #3 Genode::Cancelable_lock::lock (this=0x103c400) at /opt/genode/genode-r121/base/src/base/lock/lock.cc:137 #4 0x000000000101022e in Genode::Lock::lock (this=<value optimized out>) at /opt/genode/genode-r121/base/include/base/lock.h:35 #5 Genode::Platform::wait_for_exit (this=<value optimized out>) at /opt/genode/genode-r121/base-linux/src/core/platform.cc:50 #6 0x000000000100dfde in main () at /opt/genode/genode-r121/base/src/core/main.cc:229
Looking at your backtrace, I assume 'core' exits for any reason. Typically, this is caused by pressing CTRL-c on the command line. Technically, core's main thread blocks on a lock (that is initialized locked), which is only unlocked by the signal handler. So, there may be the very unlikely case that the lock implementation does not work on your platform... To debug the situation in core you may run it from the very beginning in GDB.
Greets