Hi Adam & all,
here the calling graph, which seems to cause the issue:
lib/src/exit.c: __do_exit () the state is set to TCB_SHUTDOWN
Afterwards the thread in shutdown progress calls __do_cleanup_and_block() -> l4th_stack_free -> l4th_pages_free -> l4rm_detach () -> l4rm_lock_region_list() -> l4lock_lock () -> IPC to semaphore lib if locked [! we have contention, threads in creation or in shutdown progress, otherwise no call to the semaphore lib is required] -> get_prio () -> sanity check TCB_ACTIVE
Here the data structure [l4th_tcb_t] is still valid and associated to the thread. This data structure is removed after l4th_stack_free() invocation by l4th_tcb_deallocate(tcb).
So it seems to be no problem in general, because the data structure is still valid and associated to the thread in shutdown progress. However a solution could be to extend the sanity check from tcb_active also to allow tcb_shutdown [bad/good don't know] or to move around the tcb_shutdown state [possibly bad idea] or to introduce another state and extend sanity check.
Best,
Alex B.
Marc CHALAND wrote:
2008/1/24, Adam Lackorzynski adam@os.inf.tu-dresden.de:
No, the thread is still alive, the '(deleted)' just means that it has already been unregistered at the name service.
Name service data is stored into fiasco data to be shown into jdb ?
Could you verify the theory that the threadlib has some strange state at that time? So basically that l4thread_get_prio is returning -L4_EINVAL
Yes, return value is -L4_EINVAL.
and then what the value of l4th_tcbs[thread].state in l4th_tcb_get is (include/__tcb.h).
state of thread is 4 : TCB_SHUTDOWN. Hope this helps ?
Regards Marc
l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers