[GRASS-dev] [GRASS GIS] #943: wxpython gui hangs after switching to cairo display driver

[GRASS GIS]

#943: wxpython gui hangs after switching to cairo display driver
------------------------------------------+---------------------------------
 Reporter:  epatton                       |       Owner:  grass-dev@…              
     Type:  defect                        |      Status:  new                      
 Priority:  critical                      |   Milestone:  6.4.3                    
Component:  wxGUI                         |     Version:  svn-develbranch6         
 Keywords:  cairo, driver, gui, wxpython  |    Platform:  Linux                    
      Cpu:  All                           |  
------------------------------------------+---------------------------------

Comment(by glynn):

 Replying to [comment:19 hamish]:

 > is there a chance that the G_spawn()'d `mon.start` or `mon.select`
 program has gotten a hold of one of the stdin/out/err pipes, and is
 holding it open, and then in the wxgui the proc.communicate() can't let
 its end go until that happens?

 Yes. fork() duplicates practically everything, including all descriptors.
 G_spawn() will only close descriptors which are explicitly requested to be
 closed (with SF_CLOSE_DESCRIPTOR) or which are implicitly closed by being
 the target of a redirection (SF_REDIRECT_FILE or SF_REDIRECT_DESCRIPTOR).
 Any descriptors which have the close-on-exec flag set will be closed in
 the child process when the new program is exec()d.

 ISTR that this is/was actually a problem for the d.resize script, as the
 new monitor inherits any descriptors from d.resize, so if d.resize
 inherits the write end of a pipe (e.g. if its stdout or stderr are pipes),
 the reader won't see EOF so long as the monitor process survives.

 > but in that case perhaps the zombie wouldn't exist? since the zombie
 exists perhaps it is d.mon's exit() which can't let go of the pipe?

 A zombie is a process which has terminated (completely), but whose parent
 is alive and hasn't yet been "reaped" by retrieving the child's exit
 status with wait(), waitpid() etc. If the parent is no longer alive, the
 child will be "adopted" by the init process which will reap it.

 For a child spawned with Python's subprocess.Popen, the .wait() or .poll()
 methods should be called on the Popen object (in the case of .poll(), it
 must be called until it returns a value other than None). Popen objects
 which are garbage-collected will have the .poll() method called from the
 finaliser; if the child process is still alive at that point, it is added
 to a list (subprocess._active) which is pruned (by calling
 subprocess._cleanup()) whenever a new Popen object is constructed. So if a
 Popen object is created, abandoned and gc'd before it completes, the
 process will remain in the zombie state until another Popen object is
 constructed.

 For a child spawned with GRASS' G_spawn() function with the SF_BACKGROUND
 option, G_spawn() returns the child's PID which must be passed to
 G_wait().

 Other than in relation to wait() etc, the existence of a zombie has no
 side effects other than occupying a slot in the process table (and
 counting toward any limit on the maximum number of processes). Descriptors
 have already been closed at that point.

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/943#comment:20>
GRASS GIS <http://grass.osgeo.org>