#2188 QT terminal can leave zombie processes

[dima]

Hi. I just stumbled upon an issue present in the qt terminal (but not in the x11 or wxt terminals). Recipe:

1. gnuplot
2. set terminal qt
3. plot x
4. In another terminal window, "kill PID" where PID is the PID of the gnuplot process

If you do this, gnuplot dies, as it should, but the child gnuplot_qt process sticks around, leaving a zombie plot window. It should go away too, like it does with the other terminals.

Thanks!

[Mike Sutton]

I have seen these zombie Qt processes recently. I was seeing this happen when the gnuplot process was not killed. I finally have a way to consistently reproduce the problem. Below are the steps required to get the zombie process. GNUTERM should be set to 'qt'.

1. pgrep -l gnuplot_qt (verify no processes)
2. gnuplot qt_zombie.gp (see below)
3. After plots are displayed, press q (quit) in window 1
4. Press q in window 2. This returns to the command prompt.
5. pgrep -l gnuplot_qt (should show a zombie process)

If you quit window 2 then window 1; no zombie process.

If you hit return to free the pause command; no zombie process.

I'm using gnuplot 4.5.1 with bug #2292 patch applied. CentOs 7.3.

Below is qt_zombie.gp

if (GPVAL_TERM eq "x11") set term x11 persist title 'WINDOW 1'
if (GPVAL_TERM eq "qt") set term qt persist title 'WINDOW 1'
set macros
set multiplot layout 6,1 scale 0.85,1.1 offset 0.05,-.07 title 'Press Q in this window first'
plot sin(x)
repl
repl
repl
repl
unset multiplot

#new window
if (GPVAL_TERM eq "x11")set term x11 2 persist title 'WINDOW 2'
if (GPVAL_TERM eq "qt")set term qt 2 persist title 'WINDOW 2'
set multiplot layout 2,2 scale 0.95,1. offset 0.0,0.0 title 'plot 2'
plot cos(x)
replot
replot
replot
unset multiplot
pause -1 'hit return'

[Ethan Merritt]

Good. A recipe to reproduce it. I can work with that.

But it doesn't seem to describe the same condition described in the original report. Dima's scenario has the main gnuplot process exit first, leaving gnuplot_qt as a zombie. Your recipe only works if the main process does not exit first.

[Ethan Merritt]

Here's the complete story:

This problem was introduced by commit bef3809754, which suppressed notification of plot windows being closed manually. Without these notifications the gnuplot_qt process doesn't realize that the plot windows have been closed, so it stays around as a zombie. Reverting that one-line commit
fixes the current zombie creation issue.

However, that commit was itself a fix for an earlier pair of problems that would be re-introduced
https://sourceforge.net/p/gnuplot/bugs/1554/
https://sourceforge.net/p/gnuplot/bugs/1753/

On linux the worst effect seems to be a warning message if you try to plot into a window that has been manually closed. If you repeat the plot command and continue there is no further difficulty, so I consider this acceptable.

On windows the down-side of reversion is worse. According to the earlier reports the sequence

  gnuplot> set multiplot
        <manually close plot window>
  gnuplot> unset multiplot

causes the program to freeze altogether. This is clearly bad.

Edit:
I found a better fix. Rather than re-enabling the Destroy-on-Close attribute, we can step through the list of known windows at the time the main program wants to exit. The list contains both active (visible) and "closed" (invisible) windows. The zombification of gnuplot_qt is due to the presence of invisible windows when "persist" mode starts. The program thinks it needs to handle events from these windows so it sticks around instead of exiting. But you can't interact with these invisible windows so they never generate any events to handle. The fix is to only stick around if there are still visible windows, and exit when the last of these is closed.

Commit 25dcefe6f