Hi Norman, thank you for your hints. I could fix the problem which was caused by a blocking call on a libc function without using Libc::with_libc. Correctly encapsulating the affected code solved the problem.
Regards, Johannes Am 09.06.2018 um 10:37 schrieb Norman Feske: > Hi Johannes, > > On 01.06.2018 11:38, Johannes Kliemann wrote: >> are nested threads (e.g. a thread class that owns an object of another >> thread class and starts it from within its entry() method) a special >> case? I noticed that the terminal session blocked from the inner thread >> (write was called from the thread but the write implementation of the >> terminal session was never executed). Putting the inner thread on the >> same level as the outer one solved the problem. > > I don't know exactly what you mean by "nesting" but I cannot think of > anything special when instantiating a 'Thread' object in the context of > another thread. By this notion, each thread - in fact, even the initial > entrypoint - of a component would be a nested thread then. > > What you observe looks like some form of deadlock. Are you able to > reproduce the problem in a simple scenario on base-linux? If yes, the > backtraces of the various threads (obtained by attaching GDB to the PID > of your component, see below) would certainly reveal the issue. > > cd build/x86_64/debug > ln -sf ld-linux.lib.so ld.lib.so > gdb ./binary_of_your_component -p <PID-of-your-component> > > Cheers > Norman > _______________________________________________ Genode users mailing list [email protected] https://lists.genode.org/listinfo/users
