#5713 closed bug (fixed)
calling exit from a thread other than the main thread returns the wrong value to caller
Reported by: | andrewbachmann | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | System/Kernel | Version: | R1/alpha1 |
Keywords: | main thread exit team | Cc: | |
Blocked By: | Blocking: | ||
Platform: | All |
Description (last modified by )
In OpenJDK, ::exit(<value>) is called from a thread other than the main thread. In this case, Haiku doesn't return <value> as the result of the program. Instead it returned 149. It is also printing "Kill Thread" but I am unclear if that is a result of my attempts to work around this issue.
AnEvilYak on IRC suggested looking at src/system/kernel/team.cpp method _user_exit_team and I believe the fix is to add the line "thread = thread->team->main_thread;" before the exit status is assigned.
Alternatively, assign the exit status and reason to both the main thread and calling thread, if that works.
Here's how to work around the bug: 1. wrap ALL calls to ::exit with a method that stores the exit value 2. use atexit() to hook up an exit handler that first signals the main thread, and then suspends itself 3. create a signal handler that kill_threads the other threads, and after they have all died, performs exit_thread() with the stored exit value
<whew!>
BeOS had this bug too although the fix was slightly different in that I called ::exit again in the signal handler instead of exit_thread. That version does not work on haiku. (hangs instead)
Change History (6)
comment:1 by , 15 years ago
Description: | modified (diff) |
---|
comment:2 by , 15 years ago
Description: | modified (diff) |
---|
comment:3 by , 15 years ago
Component: | - General → System/Kernel |
---|---|
Owner: | changed from | to
Status: | new → in-progress |
comment:4 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | in-progress → closed |
comment:5 by , 15 years ago
The fix looks good to me. I'll try to rebuild Haiku & Java soon and make sure it works. Thanks!
Should be fixed in hrev36215.