idb hangs on receiving signal

[ereisch]

We're having problems with the idb debugger hanging on us, to the point we need to send it a SIGKILL to get it to go away. Debugger version is 12.0.

Steps to reproduce:
Fire up an xterm with the debugger as its program. For example:

xterm -132 -geometry 132x30+20+20 -rightbar -sb -sl 1000 -hold -T debugger_output -n debugger_output -e "idb -gui -gdb"

Then, try to HUP (via the X-windows kill button.....hit the X in the corner depending on your window manager) the xterm window. It should shutdown the intel debugger and then itself, but instead the java process orphans itself from the xterm process, the debugger goes zombie, and the java process hangs and cannot be killed via X-windows. If you do a process listing, you have a zombie iidb process as a child of a frozen java process.

This behavior can be simulated without xterm by sending the top-level debugger process (i.e. java) a SIGHUP. The window hangs as described above. (Pressing the "X" in the window manager is a shortcut to sending the process [and all its children] a SIGHUP).

-E

[Rob_Mueller-Albrecht]

Dear E,

fixing this behavior is not going to be easy as it is probably a debugger design side effect. I will definitely esclate it to our development team for a fix though.

The IDB debugger engine "iidb" and the Eclipse RCP based GUI are two separate processes, the GUI being launched by the debugger engine.

I can't reproduce your problem exactly the way you describe, but I think I am close enough that I understand what is going on.

What happens is that when youtry andclose xterm the debugger engine gets closed, but the Java based GUI still exists as an orphan process.

If you then try to close the IDB GUI it takes a moment for it to realize that there is no underlying engine running any more and it then allowsto force a quit.

BTW - the options -gui -gdb are no longer needed since launch with GUI and GDB mode are now the default for the debugger.

Thanks, Rob

[ereisch]

Thanks for the reply. When I fire up the debugger, I get a process tree as follows:

/bin/sh /..../idb test_program
\\_ java -jar /..../org.eclipse.equinox.launcher.....jar -showsplash -gui test_program
\\_ /..../iidb -gui test_program
\\_ test_program
\\_ test_program

When you send a kill -HUP to the java process, the process tree stays as before, but the debugger GUI blocks indefinitely. This is just an outsider's perspective, but it's been our experience in the past that if you simply set up a sigaction() call at program start to handle a HUP, it usually handles the signal cleanly.

When I run the debugger in an strace session, I see that the java GUI process is blocking on a futex() address, and I suspect that there is a race condition in that if the iidb process terminates before releasing that futex() (assuming it's the one that should be releasing it), then the debugger GUI will block indefinitely. This is only a cursory glance at what's going on behind the scenes though.....I may be (and probably am) completely off-base.

Cheers,
-E

[Rob_Mueller-Albrecht]

Thanks E,

I went ahead and escalated this behavior as a defect. I'll talk with our developers about it tomorow and I will keep you posted about the availability of a fix.

Rob