[GRASS5] [bug #2324] (grass) NVIZ: child process: segmentation violation located

this bug's URL: http://intevation.de/rt/webrt?serial_num=2324
-------------------------------------------------------------------------

Subject: NVIZ: child process: segmentation violation located

Platform: GNU/Linux/i386
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: 5.3 CVS and 5.0.3

To whom it may concern:

I have narrowed down the source of the NVIZ segfault error. The error has appeared for me using both 5.0.3 and version 5.3 I picked up from CVS today in hopes this would be resolved.

The error has occured with a message like this, and can be generated even with no data using the command:
nviz -q

child killed: segmentation violation
    while executing
"exec /usr/local/grass53/etc/nviz2.2/NVWISH2.2 -f /usr/local/grass53/etc/nviz2.2/scripts/nviz2.2_script -q -name NVIZ >&@stdout"
    ("eval" body line 1)
    invoked from within
"eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f $env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script $argv -name NVIZ >&@stdout"
    invoked from within
"if {$argv == ""} {
#no arguments
eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f $env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script -name NVIZ >&@stdo..."
    (file "/usr/local/grass53/bin/nviz" line 16)

The offending segmentation fault happens on this line of etc/nviz2.2/scripts/nviz2.2_script:
    togl $BASE.canvas -rgba true -double true -depth true

Which appears to be creating some sort of gl object as a canvas element.

I thought that the problem might be in my OpenGL implementation. I am using Debian (testing). I got the error when using the xlibmesa3-glu and xlibmesa4-gl packages. I switched to the mesag3 package (the development package is mesag-dev) and NVIZ now works correctly.

The short and skinny is:

NVIZ works correctly (this bug does not exist) with Mesa-3.

NVIZ does not work with xlibmesa.

And a slightly related question: is there a new monitor implementation in the works for 5.7 with scrollbars, zoom buttons, etc? Is building one in tcl/tk appropriate? It appears that NVIZ uses a similar mechanism ...

-------------------------------------------- Managed by Request Tracker

Request Tracker wrote:

I have narrowed down the source of the NVIZ segfault error. The error
has appeared for me using both 5.0.3 and version 5.3 I picked up from
CVS today in hopes this would be resolved.

The offending segmentation fault happens on this line of etc/nviz2.2/scripts/nviz2.2_script:
    togl $BASE.canvas -rgba true -double true -depth true

Which appears to be creating some sort of gl object as a canvas element.

Yep. "Togl" is an OpenGL canvas widget for Tcl/Tk.

I thought that the problem might be in my OpenGL implementation. I am
using Debian (testing). I got the error when using the xlibmesa3-glu
and xlibmesa4-gl packages. I switched to the mesag3 package (the
development package is mesag-dev) and NVIZ now works correctly.

The short and skinny is:

NVIZ works correctly (this bug does not exist) with Mesa-3.

NVIZ does not work with xlibmesa.

Odd. It's quite unusual for crashes to be related to the use of
OpenGL. However, there are a few common linking problems,
specifically:

1. If libGL uses pthreads, it sometimes helps to explicitly pass the
-lpthread switch when linking the application.

2. SGI's libGLU is written in C++, which is never a good thing for
binary compatibility. Mesa's libGLU (which is now considered obsolete
due to the lack of the GLU 1.2 tesselator API) is written in C.

And a slightly related question: is there a new monitor implementation
in the works for 5.7 with scrollbars, zoom buttons, etc?

What you are describing isn't a monitor but a GUI. Note that monitors
aren't restricted to just XDRIVER, but also include the PNG and CELL
drivers; GUI components wouldn't be meaningful for those drivers.

On the GUI front, there is already d.dm/d.m (which are part of GRASS),
and also Radim's QGIS (which is separate).

Is building
one in tcl/tk appropriate? It appears that NVIZ uses a similar
mechanism ...

Tcl/Tk has the advantage of portability, but Tcl isn't a particularly
nice language for writing substantial applications, and Tk is fairly
limited compared to other GUI toolkits.

--
Glynn Clements <glynn.clements@virgin.net>