Hi,
I experiment a futex freeze too in a self made program.
1) I have a un-freezing technic that uses the ptrace(2) to :
- attach a frozen process,
- get the syscall number (checks that it is a sys_futex),
- get the arguments of sys_futex(2) to check it is a WAIT
and get the adress of the wait.
- poke a 0 at the adress.
That all unfreezes the process.
Do you want the code of my survfutex program ?
2) Now, I am tracking the cause and have some informations.
It appears to occur (in my code) during the execution of a
signal handler set for the SIGCLD.
When the father catches the SIGCLD, it performs some action
like fprintf(3) and free(3).
Of course, it does not occur systematicaly (it would have been too
simple).
When I suppress fprintf() and free() from the signal handler, the
father process never freezes.
My supposition is that the sys_futex() is called from glibc (may be
from brk(2) and some other syscall).
I have two kinds of bug work-arround :
The first consist in :
- blocking the SIGCLD,
- At some part of the code watch if there is a pending SIGCLD
if so, performs the wait(2) and other action out of a signal
handler. Then remove the sig pending condition.
The second consist in :
- performing the wait(2) from the signal handler and move the
struct from a list of "alive son" to a list of dead ones.
This is done with a simple linked list technic.
- From outside the signal handler, see if some son are dead.
If so, performs the rest of actions (fprint() to log the death
with the exit status, free() the struct memorizing the son).
Both technics work fine for me.
I hope it will help you.
One last thing, I suppose the bug is a general bug that does not freeze
only xmms.
Rogers Veber.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
