[GRASS-dev] [GRASS GIS] #943: wxpython gui hangs after switching to cairo display driver
GRASS GIS
trac at osgeo.org
Sat Jun 8 01:04:57 PDT 2013
#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 hamish):
by adding a little debug write to d.mon just before its final exit(), I
can see that the module was completing ok; i.e. not getting hung up in the
G_spawn(). But then something is still holding it open and it becomes a
zombie until you manually stop the cairo driver process. At which point it
releases and all is back to normal (except wxgui mouse cursor remains an
hourglass)
doing the same thing from the command line works fine.
if it was some "Graphics driver [cairo] started" text from d.mon waiting
to be flushed from the stderr buffer by python's popen.communicate(), then
for one thing the proc.communicate() should flush it, and for another why
would externally stopping the cairo driver suddenly free it?
Glynn wrote:
> Terminating a process implicitly close()s all open file descriptors,
> but the underlying object (file, socket, etc) isn't actually closed
> until no process has it open.
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?
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?
thanks,
Hamish
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/943#comment:19>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list