Opened 14 years ago
Closed 14 years ago
#244 closed defect (fixed)
Exiting thread causes Udebug begin to block forever
| Reported by: | Jiri Svoboda | Owned by: | Jiri Svoboda |
|---|---|---|---|
| Priority: | major | Milestone: | 0.4.3 |
| Component: | helenos/unspecified | Version: | mainline |
| Keywords: | Cc: | ||
| Blocker for: | Depends on: | ||
| See also: |
Description
Tomas Brambora noticed that if task creates a thread, this thread exits and then we try to open a debugging session with the task, Udebug begin method will block forever.
Change History (2)
comment:1 by , 14 years ago
comment:2 by , 14 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Fixed in changeset:head,511. In the end the only problem was that we did not make the userspace thread stoppable before it would exit. This makes the not_stoppable_count balance of both kernel and userspace threads zero when they exit. Also note that is is okay to mark an exiting thread stoppable according to definition.
Note:
See TracTickets
for help on using tickets.
It would appear that the handling of stoppability/not_stoppable_count at the entry and exit of a thread have problems stemming from code evolution (historically a thread was stoppable at entry and exit, now it is not).
What is observed: A userspace thread starts with not_stoppable_count contribution of zero. Then in uinit it gets +1. In thread_exit() it has still +1 and this stays so until the thread is destroyed. So +1 is leaked into
not_stoppable_count.Need to revisit stoppability/not_stoppable_count handling during thread creation, uspace initialization and thread termination.