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

GRASS GRASS developer
1

#943: wxpython gui hangs after switching to cairo display driver
------------------------------------------+---------------------------------
Reporter: epatton | Owner: grass-dev@lists.osgeo.org
     Type: defect | Status: new
Priority: normal | Milestone: 6.5.0
Component: Display | Version: svn-develbranch6
Keywords: cairo, driver, gui, wxpython | Platform: Linux
      Cpu: x86-64 |
------------------------------------------+---------------------------------
The wxpython Map Display window freezes and becomes unresponsive after
changing the display driver from 'default' to 'cairo'.

I have compiled Grass 6.5 from a fresh checkout from svn, set --with-
cairo, --with-cairo-libs=/usr/lib, and --with-cairo-includes=/usr/include.
One thing I just noticed is that the configure line

{{{
checking for cairo linking flags...
}}}

appears as it does above, with no confirmation about whether or not it
found cairo linking flags. But then I'm not sure it it's supposed to print
anything in a successful case, either.

I've checked my package manager, and I have libcairo2 and libcairo2-dev
installed, versions 1.8.8.

Anything else I should check? Can anyone confirm this error?

Thanks,

~ Eric.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/943&gt;
GRASS GIS <http://grass.osgeo.org>

2

#943: wxpython gui hangs after switching to cairo display driver
----------------------+-----------------------------------------------------
  Reporter: epatton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: normal | Milestone: 6.5.0
Component: Display | Version: svn-develbranch6
Resolution: | Keywords: cairo, driver, gui, wxpython
  Platform: Linux | Cpu: x86-64
----------------------+-----------------------------------------------------
Comment (by hamish):

same here. grass64 and grass7 work fine. I'm on debian/stable amd64,
yesterday's svn.

wxGUI freezes after you change the preferences->display mode to cairo and
first try to render a map.

I don't know if it's related, but I can get `d.mon -L` to die:

{{{
# grass65
export GRASS_PNGFILE=map.bmp
export GRASS_WIDTH=640
export GRASS_HEIGHT=480
export GRASS_RENDER_IMMEDIATE=TRUE
export GRASS_PNG_MAPPED=TRUE
export GRASS_PNG_READ=TRUE
d.mon -L

name description status
---- ----------- ------
PNG: GRASS_TRUECOLOR status: TRUE
PNG: collecting to file: map.bmp,
GRASS_WIDTH=640, GRASS_HEIGHT=480
HTMLMAP Create HTML Image Map running
PNG: GRASS_TRUECOLOR status: TRUE
PNG: collecting to file: map.bmp,
GRASS_WIDTH=640, GRASS_HEIGHT=480
*** glibc detected *** /usr/local/src/grass/svn/grass65/dist.x86_64-
unknown-linux-gnu/etc/mon.status: free(): invalid pointer:
0x00007f06499b3036 ***
======= Backtrace: =========
/lib/libc.so.6[0x7f064802d928]
/lib/libc.so.6(cfree+0x76)[0x7f064802fa36]
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/lib/libgrass_gis.so(G_free+0x15)[0x7f0649072611]
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/lib/libgrass_pngdriver.so[0x7f06494d89fe]
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/lib/libgrass_pngdriver.so(PNG_Graph_set+0x3f8)[0x7f06494d8e1f]
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/lib/libgrass_driver.so(COM_Graph_set+0x39)[0x7f06492cabc9]
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/lib/libgrass_driver.so(LIB_init+0x1be)[0x7f06492cc426]
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/lib/libgrass_raster.so(LOC_open_driver+0x62)[0x7f06496e4fdc]
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/lib/libgrass_raster.so(R_open_driver+0x18)[0x7f06496e41ff]
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/etc/mon.status(main+0x8f)[0x400b4b]
/lib/libc.so.6(__libc_start_main+0xe6)[0x7f0647fd81a6]
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/etc/mon.status[0x4009f9]
======= Memory map: ========
00400000-00401000 r-xp 00000000 09:02 34916230
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/etc/mon.status
00601000-00602000 rw-p 00001000 09:02 34916230
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/etc/mon.status
02496000-024b7000 rw-p 02496000 00:00 0
[heap]
7f0640000000-7f0640021000 rw-p 7f0640000000 00:00 0
7f0640021000-7f0644000000 ---p 7f0640021000 00:00 0
7f0647b9f000-7f0647bb5000 r-xp 00000000 09:00 553795
/lib/libgcc_s.so.1
7f0647bb5000-7f0647db5000 ---p 00016000 09:00 553795
/lib/libgcc_s.so.1
7f0647db5000-7f0647db6000 rw-p 00016000 09:00 553795
/lib/libgcc_s.so.1
7f0647db6000-7f0647db8000 r-xp 00000000 09:00 555034
/lib/libdl-2.7.so
7f0647db8000-7f0647fb8000 ---p 00002000 09:00 555034
/lib/libdl-2.7.so
7f0647fb8000-7f0647fba000 rw-p 00002000 09:00 555034
/lib/libdl-2.7.so
7f0647fba000-7f0648104000 r-xp 00000000 09:00 555046
/lib/libc-2.7.so
7f0648104000-7f0648303000 ---p 0014a000 09:00 555046
/lib/libc-2.7.so
7f0648303000-7f0648306000 r--p 00149000 09:00 555046
/lib/libc-2.7.so
7f0648306000-7f0648308000 rw-p 0014c000 09:00 555046
/lib/libc-2.7.so
7f0648308000-7f064830d000 rw-p 7f0648308000 00:00 0
7f064830d000-7f0648311000 r-xp 00000000 09:02 34916046
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/lib/libgrass_psdriver.6.5.svn.so
7f0648311000-7f0648510000 ---p 00004000 09:02 34916046
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/lib/libgrass_psdriver.6.5.svn.so
7f0648510000-7f0648511000 rw-p 00003000 09:02 34916046
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/lib/libgrass_psdriver.6.5.svn.so
7f0648511000-7f0648593000 r-xp 00000000 09:00 555051
/lib/libm-2.7.so
7f0648593000-7f0648792000 ---p 00082000 09:00 555051
/lib/libm-2.7.so
7f0648792000-7f0648794000 rw-p 00081000 09:00 555051
/lib/libm-2.7.so
7f0648794000-7f06487b9000 r-xp 00000000 09:00 151710
/usr/lib/libpng12.so.0.27.0
7f06487b9000-7f06489b8000 ---p 00025000 09:00 151710
/usr/lib/libpng12.so.0.27.0
7f06489b8000-7f06489b9000 rw-p 00024000 09:00 151710
/usr/lib/libpng12.so.0.27.0
7f06489b9000-7f0648a38000 r-xp 00000000 09:00 151676
/usr/lib/libfreetype.so.6.3.18
7f0648a38000-7f0648c37000 ---p 0007f000 09:00 151676
/usr/lib/libfreetype.so.6.3.18
7f0648c37000-7f0648c3d000 rw-p 0007e000 09:00 151676
/usr/lib/libfreetype.so.6.3.18
7f0648c3d000-7f0648c53000 r-xp 00000000 09:00 148994
/usr/lib/libz.so.1.2.3.3
7f0648c53000-7f0648e53000 ---p 00016000 09:00 148994
/usr/lib/libz.so.1.2.3.3
7f0648e53000-7f0648e54000 rw-p 00016000 09:00 148994
/usr/lib/libz.so.1.2.3.3
7f0648e54000-7f0648e5d000 r-xp 00000000 09:02 34915909
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/lib/libgrass_datetime.6.5.svn.so
7f0648e5d000-7f064905d000 ---p 00009000 09:02 34915909
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/lib/libgrass_datetime.6.5.svn.so
7f064905d000-7f064905e000 rw-p 00009000 09:02 34915909
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/lib/libgrass_datetime.6.5.svn.so
7f064905e000-7f06490c2000 r-xp 00000000 09:02 34915953
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/lib/libgrass_gis.6.5.svn.so
7f06490c2000-7f06492c2000 ---p 00064000 09:02 34915953
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/lib/libgrass_gis.6.5.svn.so
7f06492c2000-7f06492c4000 rw-p 00064000 09:02 34915953
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/lib/libgrass_gis.6.5.svn.so
7f06492c4000-7f06492c6000 rw-p 7f06492c4000 00:00 0
7f06492c6000-7f06492d2000 r-xp 00000000 09:02 34916041
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/lib/libgrass_driver.6.5.svn.so
7f06492d2000-7f06494d2000 ---p 0000c000 09:02 34916041
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/lib/libgrass_driver.6.5.svn.so
7f06494d2000-7f06494d3000 rw-p 0000c000 09:02 34916041
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/lib/libgrass_driver.6.5.svn.so
7f06494d3000-7f06494d5000 rw-p 7f06494d3000 00:00 0
7f06494d5000-7f06494dc000 r-xp 00000000 09:02 34916043
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/lib/libgrass_pngdriver.6.5.svn.so
7f06494dc000-7f06496dc000 ---p 00007000 09:02 34916043
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/lib/libgrass_pngdriver.6.5.svn.so
7f06496dc000-7f06496dd000 rw-p 00007000 09:02 34916043
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/lib/libgrass_pngdriver.6.5.svn.so
7f06496dd000-7f06496de000 rw-p 7f06496dd000 00:00 0
7f06496de000-7f06496ea000 r-xp 00000000 09:02 34916048
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/lib/libgrass_raster.6.5.svn.so
7f06496ea000-7f06498e9000 ---p 0000c000 09:02 34916048
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/lib/libgrass_raster.6.5.svn.so
7f06498e9000-7f06498eb000 rw-p 0000b000 09:02 34916048
/usr/local/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/lib/libgrass_raster.6.5.svn.so
7f06498eb000-7f0649907000 r-xp 00000000 09:00 555038
/lib/ld-2.7.so
7f06499b3000-7f0649ae0000 rw-s 00000000 09:02 34760511
/usr/local/src/grass/tests/imgview/map.bmp
7f0649ae0000-7f0649ae5000 rw-p 7f0649ae0000 00:00 0
7f0649b00000-7f0649b06000 rw-p 7f0649b00000 00:00 0
7f0649b06000-7f0649b08000 rw-p 0001b000 09:00 555038
/lib/ld-2.7.so
7fff50ba7000-7fff50bbc000 rw-p 7ffffffea000 00:00 0
[stack]
7fff50bff000-7fff50c00000 r-xp 7fff50bff000 00:00 0
[vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0
[vsyscall]
}}}

apparently GRASS_PNG_READ being set is what triggers it.

?,
Hamish

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

3

#943: wxpython gui hangs after switching to cairo display driver
----------------------+-----------------------------------------------------
  Reporter: epatton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: normal | Milestone: 6.5.0
Component: Display | Version: svn-develbranch6
Resolution: | Keywords: cairo, driver, gui, wxpython
  Platform: Linux | Cpu: x86-64
----------------------+-----------------------------------------------------
Comment (by hamish):

(and I never started the HTMLMAP driver manually)

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

4

#943: wxpython gui hangs after switching to cairo display driver
----------------------+-----------------------------------------------------
  Reporter: epatton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: normal | Milestone: 6.5.0
Component: Display | Version: svn-develbranch6
Resolution: | Keywords: cairo, driver, gui, wxpython
  Platform: Linux | Cpu: x86-64
----------------------+-----------------------------------------------------
Comment (by glynn):

Replying to [comment:1 hamish]:

> I don't know if it's related, but I can get `d.mon -L` to die:
>
{{{
...
export GRASS_RENDER_IMMEDIATE=TRUE
...
d.mon -L
}}}

I wouldn't expect GRASS_RENDER_IMMEDIATE and d.mon to work well together.

In particular, mon.status calls R_open_driver() repeatedly, which may not
work with direct rendering (i.e. R_close_driver() may not restore
everything sufficiently for a subsequent R_open_driver() to work; this
case won't have had much testing).

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/943#comment:3&gt;
GRASS GIS <http://grass.osgeo.org>

5

#943: wxpython gui hangs after switching to cairo display driver
----------------------+-----------------------------------------------------
  Reporter: epatton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: normal | Milestone: 6.5.0
Component: Display | Version: svn-develbranch6
Resolution: | Keywords: cairo, driver, gui, wxpython
  Platform: Linux | Cpu: x86-64
----------------------+-----------------------------------------------------
Comment (by glynn):

Replying to [ticket:943 epatton]:

> I have compiled Grass 6.5 from a fresh checkout from svn, set --with-
cairo, --with-cairo-libs=/usr/lib, and --with-cairo-includes=/usr/include.

You should never need to specify /usr/lib or /usr/include explicitly
(however, recent versions of GCC will explicitly ignore them, so it's
harmless).

On Linux, you should only need --with-cairo, which obtains the compiling
and linking flags via pkg-config. The --with-cairo-includes, --with-cairo-
libs, and --with-cairo-ldflags switches are there for platforms lacking
pkg-config.

> One thing I just noticed is that the configure line
>
{{{
checking for cairo linking flags...
}}}
>
> appears as it does above, with no confirmation about whether or not it
found cairo linking flags. But then I'm not sure it it's supposed to print
anything in a successful case, either.

It prints whatever you specified for --with-cairo-ldflags. If you didn't
use it, then it won't print anything.

If the cairo driver gets built, there's nothing wrong with the configure
switches. If it doesn't work, that suggests a bug in either the driver or
the GUI.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/943#comment:4&gt;
GRASS GIS <http://grass.osgeo.org>

6

#943: wxpython gui hangs after switching to cairo display driver
----------------------+-----------------------------------------------------
  Reporter: epatton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: normal | Milestone: 6.5.0
Component: Display | Version: svn-develbranch6
Resolution: | Keywords: cairo, driver, gui, wxpython
  Platform: Linux | Cpu: x86-64
----------------------+-----------------------------------------------------
Comment (by hamish):

this still locks up with 64bit grass 6.5 + debian/stable.

I wonder if it is the different enviro vars needed for Cairo in 6.5?

{{{
export GRASS_CAIRO_READ=TRUE
export GRASS_CAIRO_MAPPED=TRUE
export GRASS_CAIROFILE=map.png
}}}

in 6.4svn & 7svn on the same machine it works.
does 6.5svn + 32bit work?

Hamish

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

7

#943: wxpython gui hangs after switching to cairo display driver
----------------------+-----------------------------------------------------
  Reporter: epatton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: normal | Milestone: 6.5.0
Component: Display | Version: svn-develbranch6
Resolution: | Keywords: cairo, driver, gui, wxpython
  Platform: Linux | Cpu: x86-64
----------------------+-----------------------------------------------------
Comment (by epatton):

Yep, still locks up here too - 64bit, 6.5.svn on Ubuntu 9.10.

I tried exporting the variables you posted to .grass.bashrc, to no avail.

I have no way of testing on a 32-bit system.

~ Eric.

--
Ticket URL: <http://trac.osgeo.org/grass/ticket/943#comment:6&gt;
GRASS GIS <http://grass.osgeo.org>

8

#943: wxpython gui hangs after switching to cairo display driver
----------------------+-----------------------------------------------------
  Reporter: epatton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: normal | Milestone: 6.5.0
Component: Display | Version: svn-develbranch6
Resolution: | Keywords: cairo, driver, gui, wxpython
  Platform: Linux | Cpu: x86-64
----------------------+-----------------------------------------------------
Comment (by glynn):

Replying to [comment:5 hamish]:

> this still locks up with 64bit grass 6.5 + debian/stable.
>
> I wonder if it is the different enviro vars needed for Cairo in 6.5?
>
{{{
export GRASS_CAIRO_READ=TRUE
export GRASS_CAIRO_MAPPED=TRUE
export GRASS_CAIROFILE=map.png
}}}

GRASS_CAIRO_MAPPED only works with BMP images, not any of the other
formats. If the filename doesn't end in ".bmp", GRASS_CAIRO_MAPPED is
silently ignored.

The file must have the correct size (width * height * 4 + HEADER_SIZE
bytes).

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

9

#943: wxpython gui hangs after switching to cairo display driver
----------------------+-----------------------------------------------------
  Reporter: epatton | Owner: grass-dev@lists.osgeo.org
      Type: defect | Status: new
  Priority: normal | Milestone: 6.5.0
Component: Display | Version: svn-develbranch6
Resolution: | Keywords: cairo, driver, gui, wxpython
  Platform: Linux | Cpu: All
----------------------+-----------------------------------------------------
Changes (by hamish):

  * cpu: x86-64 => All

Comment:

Replying to [comment:6 epatton]:
> I have no way of testing on a 32-bit system.

ok, tried on 32-bit debian/lenny (stable). locks up, need to use `xkill`.

so both 32 and 64 bit, ubuntu and debian, grass 6.5 only.

do any non-.deb family users have cairo working with the wxGUI?

Hamish

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

10

#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 |
------------------------------------------+---------------------------------
Changes (by hamish):

  * priority: normal => critical
  * component: Display => wxGUI
  * milestone: 6.5.0 => 6.4.3

Comment:

ok, seems like two bugs,

[debian/squeeze on amd64, testing in both relbr64 and devbr6, cairo 1.10]

with GRASS_PNG_READ as in the example in comment:1, d.mon still crashes
with,
{{{
G643svn> export GRASS_PNGFILE=map.bmp
G643svn> export GRASS_PNG_READ=TRUE
G643svn> d.mon -L
*** glibc detected *** status: free(): invalid pointer:
...
G643svn> echo $?
1
}}}
(as above)

If I `touch map.bmp` first then d.mon runs ok.
So it either needs to test if the file exists and exit with an error, or
test if it exists and skip trying to read it, or create it if it's
missing. (maybe d.mon shouldn't be creating it..)

---

in the wxGUI preferences, after changing the Map Display -> Display driver
to "cairo" I get this error in the command console:

{{{
Settings applied to current session but not saved
ERROR: Rendering failed. Details: File </tmp/tmpsF0WNE.ppm>
not found
}}}

however, there is an empty file in /tmp/ called `tmpsF0WNE`. (no .ppm)

?,
Hamish

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

11

#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):

the following patch against devbr6 changes the error message from "File
<...> not found" to "ERROR: Rendering failed. Details: Error reading PPM
file" (the file exists but is empty).

{{{
Index: gui/wxpython/core/render.py

--- gui/wxpython/core/render.py (revision 56191)
+++ gui/wxpython/core/render.py (working copy)
@@ -87,13 +87,14 @@
                          self.opacity, self.hidden))

          # generated file for each layer
- self.gtemp = tempfile.mkstemp()[1]
- self.maskfile = self.gtemp + ".pgm"
          if self.type == 'overlay':
- self.mapfile = self.gtemp + ".png"
+ tempfile_sfx =".png"
          else:
- self.mapfile = self.gtemp + ".ppm"
-
+ tempfile_sfx =".ppm"
+ self.mapfile = tempfile.mkstemp(suffix = tempfile_sfx)[1]
+ # do we need to `touch` the maskfile so it exists?
+ self.maskfile = self.mapfile.rsplit(".",1)[0] + ".pgm"
+
      def __del__(self):
          Debug.msg (3, "Layer.__del__(): layer=%s, cmd='%s'" %
                     (self.name, self.GetCmd(string = True)))
}}}

shooting in the dark:
I guess the error means that g.pnmcomp is trying to read from the existing
GRASS_CAIROFILE before adding to it as GRASS_CAIRO_READ is set(?), or
maybe the GRASS_RENDER_IMMEDIATE=TRUE is causing the PNG driver to be used
instead?

(I notice GRASS_PNG_READ is referenced in a few places, but
GRASS_CAIRO_READ is not at all)

Hamish

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

12

#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):

I notice in wxpython/core/render.py sets GRASS_COMPRESSION=0, but that
doesn't exist, GRASS_PNG_COMPRESSION does. Having that mis-set probably
doesn't help rendering speed & cpu load any.

broken since forever; fixed in all branches.

wrt the tempfiles mentioned in comment:10, I wonder if we can at least
mitigate the left-over-file problem (#560) by putting them in the GISRC
tempdir with something like:

{{{
tempfile.mkstemp(suffix = '.ppm',
    prefix = os.path.basename(os.path.dirname(os.getenv('GISRC'))) + os.sep
+ 'tmp_')
}}}

(? is the GISRC enviro var reset in core/render.py there for the GCP tool,
or..?)

Hamish

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

13

#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):

Hi,

a few cleanups and fixes applied to devbr6 in r56443. The main problem
there was GRASS_RENDER_IMMEDIATE always being set to TRUE, which in GRASS
6 always triggers the PNG driver instead.

Now the error message is by d.rast (e.g.) and has to do with the monitor
not accepting connections. Interestingly enough, if I have the x0 XMONITOR
started and selected (on linux) and the cairo driver selected as the wxGUI
rendering mode, it renders to the Xmon much like the old tcl/tk GUIs
would.

But as for the Cairo driver, trying to start it still locks up the wxGUI,
as per the original bug report, so is currently commented out.
{{{
    RunCommand('d.mon', start = 'cairo')
}}}

I had an hourglass mouse cursor on the Map Display window, and could not
change tabs or do anything with the Layer Manager window, although if I
dragged it around and moved other windows over the top of it it still
looked ok after dragging them off. But I had to use `xkill` to get rid of
it, as neither the Map Display or the Layer manager's "X" window
decoration worked.

Hamish

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

14

#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):

oh, and GRASS_RENDER_IMMEDIATE is now ''not'' set at the time that d.mon
is called to start the cairo driver, but the GUI still locks up anyway.

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

15

#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):

Hi,

a little more debug (I had to log it to a file, since I couldn't switch
back to the output tab after the lock-up).

start g.gui, prefs -> map display -> display driver: cairo -> apply.
(blank map display)
{{{
g.pnmcomp opacity=1.0 mask=/tmp/tmprA1z8Q.pgm height=537 width=698 \
   background=255:255:255 input=/tmp/tmprA1z8Q.ppm
output=/tmp/tmpxRSoaJ.ppm
}}}

(those .ppm,.pgm are the right size, but all pixels black)

Sometimes I get no rendered map, but do see this error on the layer
manager output tab: (the message is a G_fatal_error() from g.pnmcomp)
{{{
ERROR: Rendering failed. Details: Error reading PPM file
}}}

and sometimes this in the terminal:
{{{
.: Fatal IO error 0 (Success) on X server :0.0.
}}}

when it tries to run "`d.mon start=cairo select=cairo`" the GUI lockup
happens on this line of gui/wxpython/core/gcmd.py:
{{{
     Debug.msg(3, "gcmd.RunCommand(): decoding string")
     stdout, stderr = map(DecodeString, ps.communicate())
}}}

so something is holding the stderr pipe open?

it's a bit funny, the order of `RunCommand()`s has the driver not started
the first time:
{{{
d.mon -p
d.rast --q -o map=elevation.dem@PERMANENT
d.mon stop=cairo
g.pnmcomp opacity=1.0 mask=/tmp/tmpEdfEuF.pgm ...
  ERROR: Rendering failed. Details: Error reading PPM file
[hit the eyeball redraw button]
d.mon -p
d.mon start=cairo select=cairo
[lockup]
}}}

... ah, the cairo driver was still running since the last crash, so it
didn't get started a second time before the "d.rast". ..nevermind.

adding quiet=True to the 'd.mon start=' command doesn't help, so I suspect
it is the stderr pipe which is holding things up?

Hamish

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

16

#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):

re the X error,
  http://www.gtkforums.com/viewtopic.php?f=3&t=55792

quote:
{{{
There could be several problems here first one is related to this I found
by doing a search http://developer.gnome.org/gtk-faq/stable/x505.html. So
if you use fork() and then use exit() you have effectively closed the
socket
to the X11 server.

Another problem could be that you have a X11 socket connection created in
the parent via GTK and then trying to reuse it in the child processes with
the data entering the socket in a bad order.
}}}

(another web search mentions that X is perhaps not thread-safe)

I'm testing with Python 2.6.6 btw.

Hamish

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

17

#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):

Adding a ps.poll() right before the ps.communicate() in
wxpython/core/gcmd.py `RunCommand()` doesn't help much, it returns "None"
(i.e. the process is still running).

looking at "`ps fax`" during the lockup shows that d.mon has become a
zombie:
{{{
22954 pts/0 SNl 0:02 wxgui
/home/hamish/src/grass/svn/grass65/dist.x86_64-unknown-linux-
gnu/etc/wxpython/wxgui.py
23018 pts/0 ZN 0:00 \_ [d.mon] <defunct>
23020 pts/0 SN 0:00 /home/hamish/src/grass/svn/grass65/dist.x86_64
-unknown-linux-gnu/driver/cairo cairo dev/fifo.8a dev/fifo.8b
}}}

the d.mon goes away along with the wxgui as soon as I `xkill` the GUI
window, the cairo process keeps running until I manually do "d.mon
stop=cairo", as expected.

Hamish

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

18

#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):

If I run "`d.mon stop=cairo`" from the terminal's command line while the
GUI is locked up, life returns to the GUI, although there is a traceback
to do with opacity shown in the output tab after:
{{{
Command 'd.rast -o map=elevation.dem@PERMANENT' failed
Details: No graphics monitor has been selected for output.
}}}

and the mouse cursor remains as an hourglass. But you can use the menus
and go to prefs and switch back to the "default" display driver, then
render maps the old way, etc.

Hamish

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

19

#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:15 hamish]:

> http://developer.gnome.org/gtk-faq/stable/x505.html.

The content of that page is nonsense.

The difference between exit() and _exit() is the the former flushes
streams (FILE*) and calls any handlers registered with atexit() while the
latter doesn't. Unless something creates a FILE* for the socket with
fdopen() (Xlib doesn't), the distinction doesn't matter.

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. This is true for an explicit close() call as well as
an implicit close due to process termination.

> (another web search mentions that X is perhaps not thread-safe)

None of this has anything to do with display drivers in general or the
cairo driver in particular. None of them use GTK, GDK, or threads.

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

20

#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&gt;
GRASS GIS <http://grass.osgeo.org>