bugGNU Octave - Bugs: bug #42665, Windows (Xming) gnuplot viewers...

 
 

bug #42665: Windows (Xming) gnuplot viewers crash, leaving defunct processes on host machine

Submitter:  Colin Foster <cfoster>
Submitted:  Wed 02 Jul 2014 04:32:38 PM UTC
   
 
Category:  Plotting with gnuplot Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Duplicate Assigned to:  None
Originator Name:  Colin Foster Open/Closed:  * Closed
Release:  * 3.8.1 Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 09 Feb 2016 10:44:40 AM UTC, comment #7: 

I think this is not an Async error but maybe due to the use of GLX, which XMing does not support. I get an empty X win plot. The program does not crash, nor report an error.

I had the same issue on a native Linux box until I updated GLX.

Ben <bkeitch>
Wed 09 Jul 2014 02:55:52 PM UTC, comment #6: 

Yes, this is the same behavior I observe (except I can't figure out how to close an SSH session while leaving the octave process running on the remote).

The reason for zombie processes is that the gnuplot process has exited (probably because gnuplot detected that your DISPLAY disconnected) but Octave is still running and has not cleaned up the child process resources that it spawned. I can achieve the same result in a desktop session by simply plotting a gnuplot figure and then killing the gnuplot process outside of Octave. But once Octave is killed, the zombies are taken care of by the system. This is standard expected Unix behavior.

So I think this is only partly a bug in Octave, but the main issue you're having is that the connection is closed, killing gnuplot but not killing Octave. You should either arrange for your users to "close all" before exiting, or to actually exit Octave before closing putty, figure out how to make putty close the SSH session properly, or have a cleanup process on the server that takes care of leftover Octave processes that users have left behind after logging off. Having leftover unused running Octave sessions seems more wasteful and serious to me than defunct gnuplot processes. Fix that problem with your workflow and you won't have zombie processes on your system.

There is already another bug about Octave creating zombie processes in a different way, so I'll close this bug as a duplicate of bug #37591. The eventual fix for that bug may mean no more gnuplot processes left over, but that's not the real problem with your setup.

Mike Miller <mtmiller>
Group Member
Wed 09 Jul 2014 02:31:09 PM UTC, comment #5: 

Follow up: After kill -9 the octave session, the zombie process disappeared

Colin Foster <cfoster>
Wed 09 Jul 2014 02:27:23 PM UTC, comment #4: 

Yes, octave is still running actually:

ps aux | grep octave
191:user      3674  0.0  0.5 240380 42104 ?        S    Jun24   0:09 /usr/local/bin/octave-cli-3.8.0
202:user     12074  0.0  0.4 235984 37060 ?        S    Jun26   0:03 /usr/local/bin/octave-cli-3.8.0
206:user     24623  0.0  0.4 231440 33180 ?        S    Jul07   0:00 /usr/local/bin/octave-cli-3.8.0

Note the similarity with these pids vs the ones mentioned before.

Perhaps this is an issue with how PuTTY closes an SSH session?

Colin Foster <cfoster>
Mon 07 Jul 2014 11:50:37 PM UTC, comment #3: 

I can't reproduce this here (with a Linux-to-Linux SSH session). When the SSH session is closed or killed, Octave exits, which causes the gnuplot processes to be cleaned up. Is octave still running on your server at the same time as you see the gnuplot zombie processes appear?

Mike Miller <mtmiller>
Group Member
Mon 07 Jul 2014 10:54:24 PM UTC, comment #2: 

"Thanks for your bug report. For clarity, is the bug that gnuplot figures are "crashing" (disappearing?), or that Octave is crashing, or that zombie processes are being left behind on your server when the clients are done with their Octave session?"

My apologies: Zombie processes are being left behind on my server when the clients are done with their Octave session.



"What do you mean by an "Octave server"? Is each client running its own instance of Octave over an SSH session? If so, then when Octave exits the gnuplot processes should be cleaned up."

Yes, each client is running octave over SSH through PuTTY, using X11 forwarding to xming.


"Or do you mean each client is somehow connecting to a single instance of Octave that stays running in the background? "

No, each SSH instance starts its own Octave session.



Recreating the issue:
Start xming
ssh to the server, with X11 forwarding, from PuTTY
Create a plot using gnuplot:

figure
x=0:.01:2*pi
y=sin(x)
plot(x,y)

Check processes on server:
  ps aux | grep gnuplot
  253:user     24624  0.0  0.1 191732 12536 pts/19   S+   22:43   0:00 gnuplot
  254:user     24626  0.0  0.0  27560  1632 pts/19   S+   22:43   0:00 gnuplot_x11
Close PuTTY by clicking on the X in windows

Check processes on server:
  ps aux | grep gnuplot
  250:user     24624  0.0  0.0      0     0 ?        Z    22:43   0:00 [gnuplot] <defunct>



Looking at this log, it seems that two instances are being created, gnuplot and gnuplot_x11. The latter gets terminated. The former gets abandoned.

Colin Foster <cfoster>
Thu 03 Jul 2014 02:44:38 PM UTC, comment #1: 

Thanks for your bug report. For clarity, is the bug that gnuplot figures are "crashing" (disappearing?), or that Octave is crashing, or that zombie processes are being left behind on your server when the clients are done with their Octave session?

I can create a zombie gnuplot process if I make a plot and then "pkill gnuplot" from outside of Octave, while leaving Octave running. If Octave then runs "close all" it reaps the child process and all is good.

What do you mean by an "Octave server"? Is each client running its own instance of Octave over an SSH session? If so, then when Octave exits the gnuplot processes should be cleaned up.

Or do you mean each client is somehow connecting to a single instance of Octave that stays running in the background? Because I could definitely see zombies accumulating if nothing is actively cleaning up those gnuplot subprocesses correctly.

Mike Miller <mtmiller>
Group Member
Wed 02 Jul 2014 04:32:38 PM UTC, original submission:  

The setup that I am using is unique. Several Windows clients use xming and putty to run from an octave server.

I am not sure the method that is being used to exit the putty / xming setup, or how gracefully it is being closed, but gnuplot processes are left defunct on the host machine.

I am running 3.8.1, possibly with a single bug fix from the waitbar function compiled in. Gentoo OS.

I am not sure if this is an issue with gnuplot, octave, putty, xming, etc. so it might not be relevant but I though I'd log it somewhere.


ps aux | grep gnuplot
203:user      3919  0.0  0.0      0     0 ?        Z    Jun24   0:00 [gnuplot] <defunct>
206:user     12092  0.0  0.0      0     0 ?        Z    Jun26   0:00 [gnuplot] <defunct>

Colin Foster <cfoster>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bkeitch (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by cfoster (Submitted the item)
  • -email is unavailable- added by cfoster
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2014-07-09 mtmiller Item GroupSegfault, Bus Error, etc. Other
        StatusNeed Info Duplicate
        Open/ClosedOpen Closed
        Dependencies- Depends on bugs #37591
    2014-07-03 mtmiller StatusNone Need Info
    2014-07-02 cfoster Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code