On 02/11/2016 01:57 PM, Charles Kiorpes wrote: > > I attempted to run several tests: 'task-1', 'event-1', and 'mutex-1'. > Each of these hung indefinitely. A gdb trace indicated that they were > hanging on __libc_do_syscall() within __pthread_cond_wait() within > threadobj_cond_wait(). > > I have attached the full backtrace from mutex-1 as mutex-1_bt.txt >
Ok, if the test suite does not pass, something is badly wrong, so we should investigate that hang issue before anything else. The backtrace reveals that copperplate cannot handshake with a newly spawned task, this is the purpose of the wait_on_barrier() call over the context of rt_task_start(). That barrier should be signaled by a call to threadobj_notify_entry() from the internal trampoline code of the emerging thread (task_entry() in alchemy/task.c). - maybe task_prologue_2() (alchemy/task.c) which is called earlier hangs indefinitely, and therefore prevents threadobj_notify_entry() from running? - maybe the new thread does not even start for some reason, are we sure task_entry() is reached (e.g. do we hit a breakpoint there?) Could you inspect the current thread list under gdb when the program hangs? Also, I would recommend to enable full debugging for now (--enable-debug=full) to get accurate line information, assuming the issue should still show up with a non-optimized code. Hopefully. -- Philippe. _______________________________________________ Xenomai mailing list [email protected] http://xenomai.org/mailman/listinfo/xenomai
