Hi again,
I am unsure about the startup sequence of the init task (or any other task other than core, for that matter). The setup looks like this:
Task Thread Core main (initializes core, sleeps) activation (used as service provider by core's threads) pager (pager for all(?) threads started by core) init(0) (service thread for init) Init init(1)
Now init(1) calls init(0), does some initialization in finally gets stuck in __cxa_guard_acquire. The stack trace looks like this: ========================= 1 0x182818 .... 0x159110 __cxa_guard_acquire(T) + 0x20 = 0x1590f0 2 0x182838 32 0x15d31c Genode::env()(T) + 0x2c = 0x15d2f0 3 0x182868 48 0x1591b5 malloc(t) + 0x25 = 0x159190 4 0x182898 48 0x1596c8 __cxa_allocate_exception(T) + 0x28 = 0x1596a0 5 0x1828d8 64 0x15f00f Genode::Ipc_client::_call()(T) + 0x11f = 0x15eef0 6 0x182918 64 0x15dcb3 Genode::Parent_client::session(char const*, char const*)(W) + 0x183 = 0x15db30 7 0x1829b8 160 0x15cdf5 Genode::Platform_env::Platform_env()(W) + 0xb5 = 0x15cd40 8 0x1829d8 32 0x15d32c Genode::env()(T) + 0x3c = 0x15d2f0 9 0x182a08 48 0x1591b5 malloc(t) + 0x25 = 0x159190 10 0x182a28 32 0x157a2c __register_frame(T) + 0x2c = 0x157a00 11 0x182a38 16 0x1590e0 init_exception_handling()(T) + 0x20 = 0x1590c0 12 0x182a58 32 0x163168 _main(T) + 0x28 = 0x163140 13 0x0 .... 0x1631c0 _start(T) + 0xc = 0x1631b4 =========================== It is unclear to me, why init has to grab a lock. Is it using data structures that reside in shared memory with core? What should happen next?
Many thanks in advance, Steffen
Hello Steffen
On Friday, 21. May 2010 14:44:41 Steffen Liebergeld wrote:
Now init(1) calls init(0), does some initialization in finally gets stuck in __cxa_guard_acquire. The stack trace looks like this:
what do you mean with 'it gets stuck', does it spin at: base/src/base/cxx/guard.cc:37 ?
It is unclear to me, why init has to grab a lock. Is it using data structures that reside in shared memory with core? What should happen next?
This is a generic implementation of the c++ support library for all applications, regardless of running single- or multi-threaded (in fact init also becomes multi-threaded after its first initialization). The functions __cxa_guard_aquire and __cxa_guard_release are used to guard the construction of static objects in C++ and are required by gcc. Imagine a static single object used by different threads (singleton pattern), like the Genode::env() function returns one:
Env *env() { static Genode::Platform_env _env; return &_env; }
This pattern is often found in Genode components, which prevailing run multi-threaded, that's why you need this lock-like mechanism.
regards Stefan
Hi,
I think we probably need a different malloc() implementation (or a Genode-specific __cxa_allocate_exception() implementation) in the cxx lib that doesn't cause exceptions to be thrown, because what your stack trace shows is that with the current implementation we can get an exception thrown inside init_exception_handling() itself and also potentially infinite recursive calls of malloc() .
For now, perhaps you can find out why this particular exception is thrown in Genode::Ipc_client::_call() (in base-fiasco/src/base/ipc/ipc.cc)?
Christian
Hi,
On Friday, 21. May 2010 16:43:15 Christian Prochaska wrote:
Hi,
I think we probably need a different malloc() implementation (or a Genode-specific __cxa_allocate_exception() implementation) in the cxx lib that doesn't cause exceptions to be thrown, because what your stack trace shows is that with the current implementation we can get an exception thrown inside init_exception_handling() itself and also potentially infinite recursive calls of malloc() .
Of course, you're right with your diagnosis, regarding the exception thrown during exception initialization - I was blind ;-)
Nevertheless, I don't think Genode needs another malloc implementation here.
In Genode, the child process starts naked, meaning it has no resources (except: bss, data and text segment and a capability to communicate to it's parent) if it wants some resource or service it has to open a session (e.g.: a RAM session) and therefore needs to talk to it's parent. If the initial communication to it's parent fails, this is the real problem, which has to be solved.
As far as I understood Steffen correctly, he ports Genode to a new platform and it looks like init's first IPC call to it's parent (core) fails, probably because your platform's IPC code doesn't work fully correct (e.g. some trouble with the parent-capability given to init?).
regards Stefan
Am 21.05.2010 16:43, schrieb Christian Prochaska:
Hi,
I think we probably need a different malloc() implementation (or a Genode-specific __cxa_allocate_exception() implementation) in the cxx lib that doesn't cause exceptions to be thrown, because what your stack trace shows is that with the current implementation we can get an exception thrown inside init_exception_handling() itself and also potentially infinite recursive calls of malloc() .
For now, perhaps you can find out why this particular exception is thrown in Genode::Ipc_client::_call() (in base-fiasco/src/base/ipc/ipc.cc)?
Thanks. An IPC error occurred and as a result an exception was thrown.
Greetings, Steffen
Am 21.05.2010 15:41, schrieb Stefan Kalkowski:
Hello Steffen
On Friday, 21. May 2010 14:44:41 Steffen Liebergeld wrote:
Now init(1) calls init(0), does some initialization in finally gets stuck in __cxa_guard_acquire. The stack trace looks like this:
what do you mean with 'it gets stuck', does it spin at: base/src/base/cxx/guard.cc:37 ?
Yes.
This happens after an Exception that was thrown as a result of an IPC error. I am investigating;-)
Many thanks for your help.
Greetings, Steffen
-
Christian Prochaska -
Stefan Kalkowski -
Steffen Liebergeld