Hamish,
I dug back into some of my old archives from when I had looked into
going back to an nviz start-up script.
I had got most of the way there, but I think there is still some
problems. For example calling nviz with no arguments will not start the
GUI.
The original issue came about from trying to run nviz in the backgound
(nviz -q &). The update that I have attached gets around this.
Anyway I have attached a tar file with the modifications that I had
made. The script "nviz" could probably use some improving.
Anyway, take a look and see what else could be done to improve this.
Hope it helps.
--
Bob
On Wed, 2006-03-08 at 20:55 +1300, Hamish wrote:
> > > Perhaps there's another clue here; when I run nviz from CLI, I get:
> > >
> > > GRASS 6.1.cvs (Cheticamp):~ > nviz elevation=Cheticamp98.5.ave.fill
> > > Loading Data
> > > Update elev null mask
> > > Loading Data
> > > translating colors from fp
> > > *Segmentation fault*
> > > (my emphasis)
> >
> > A segfault. I suppose devs would not mind it if you could provide a
> > stacktrace. See here for guiding if you don't mind doing this (for
> > this purpose, it would be good if your Grass was not built with any
> > optimisations nor stripping).
> > http://www.qgis.org/index.php?option=com_content&task=view&id=74&Itemid=58
>
>
> This is not so easy for NVIZ. Or at least it wasn't -- nviz used to be a
> script which called a C binary which ran a hybrid TclTk module. Getting
> it to run in the debugger was a real chore of setting up the correct
> environment. When this bug first cropped up I spent a fair bit of time
> trying to track it down without any luck.
>
> My best guess to the cause was a threading issue somewhere in the code
> (debian tcl8.4 uses threading while 8.3 doesn't). ???
>
> Bob has since changed things a bit and `which nviz` now calls the binary
> directly. Maybe it is time to try again....
>
> configure with:
> CFLAGS="-ggdb -Wall" ./configure
>
> .. and recompile using tcl8.4-dev and tk8.4-dev.
>
> I use kdbg as a gdb frontend. Others use ddd, etc
>
> G61 > kdbg `which nviz`
>
> Execution->Arguments
> Run with these arguments: elev=elevation
>
> "Program received signal SIGFPE, Arithmetic exception."
>
> Not much use, just tells me it fails somewhere in the Tk_main() call.
>
>
> Let's try gdb directly:
>
> G61> gdb `which nviz`
> GNU gdb 6.3-debian
> [...]
> This GDB was configured as "i386-linux"...Using host libthread_db library "/lib/libthread_db.so.1".
>
> (gdb) run elev=elevation.dem
> Starting program: /usr/local/src/grass/grass61/dist.i686-pc-linux-gnu/bin/nviz elevation.dem
> [Thread debugging using libthread_db enabled]
> [New Thread 16384 (LWP 7550)]
> [New Thread 32769 (LWP 7551)]
> [New Thread 16386 (LWP 7552)]
> Loading Data
> Update elev null mask
> Loading Data
> translating colors
> 99%
> Program received signal SIGFPE, Arithmetic exception.
> [Switching to Thread 16384 (LWP 7550)]
> 0x42126ae0 in __driUtilCreateScreen () from /usr/X11R6/lib/modules/dri/r200_dri.so
>
> (gdb) l
> 29 *----------------------------------------------------------------------
> 30 */
> 31
> 32 int main(int argc, /* Number of command-line arguments. */
> 33 char **argv /* Values of command-line arguments. */
> 34 )
> 35 {
> 36 int i;
> 37
> 38 Tcl_FindExecutable(argv[0]);
>
> ### HB: this is visualization/nviz/src/nvizMain.c
>
> (gdb) bt
> #0 0x42126ae0 in __driUtilCreateScreen () from /usr/X11R6/lib/modules/dri/r200_dri.so
> #1 0x4212667b in __driUtilCreateScreen () from /usr/X11R6/lib/modules/dri/r200_dri.so
> #2 0x421267bf in __driUtilCreateScreen () from /usr/X11R6/lib/modules/dri/r200_dri.so
> #3 0x420942b2 in __driUtilCreateScreen () from /usr/X11R6/lib/modules/dri/r200_dri.so
> #4 0x420942d9 in __driUtilCreateScreen () from /usr/X11R6/lib/modules/dri/r200_dri.so
> #5 0x42011c5a in __driUtilCreateScreen () from /usr/X11R6/lib/modules/dri/r200_dri.so
> #6 0x42013d7c in __driUtilCreateScreen () from /usr/X11R6/lib/modules/dri/r200_dri.so
> #7 0x420141e8 in __driUtilCreateScreen () from /usr/X11R6/lib/modules/dri/r200_dri.so
> #8 0x4212b1bc in __driUtilCreateScreen () from /usr/X11R6/lib/modules/dri/r200_dri.so
> #9 0x41ffd35d in __driUtilUpdateDrawableInfo () from /usr/X11R6/lib/modules/dri/r200_dri.so
> #10 0x40853195 in _glthread_SetTSD () from /usr/X11R6/lib/libGL.so.1
> #11 0x408532ec in glXCreateContext () from /usr/X11R6/lib/libGL.so.1
> #12 0x080628d7 in Togl_MakeWindowExist (togl=0x81b1898) at togl.c:1451
> #13 0x0806172f in Togl_Configure (interp=0x807bfb0, togl=0x81b1898, argc=6, argv=0xbfffe778, flags=0)
> at togl.c:905
> #14 0x08061e7f in Togl_Cmd (clientData=0x808c6e0, interp=0x807bfb0, argc=8, argv=0xbfffe770)
> at togl.c:1103
> #15 0x406fc66f in TclInvokeStringCommand () from /usr/lib/libtcl8.4.so.0
> #16 0x406fd6a4 in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so.0
> #17 0x407249c8 in TclCompEvalObj () from /usr/lib/libtcl8.4.so.0
> #18 0x40723f0b in TclCompEvalObj () from /usr/lib/libtcl8.4.so.0
> #19 0x40757147 in TclObjInterpProc () from /usr/lib/libtcl8.4.so.0
> #20 0x406fd6a4 in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so.0
> #21 0x406fe254 in Tcl_EvalEx () from /usr/lib/libtcl8.4.so.0
> #22 0x40740a24 in Tcl_FSEvalFile () from /usr/lib/libtcl8.4.so.0
> #23 0x4070b5ff in Tcl_SourceObjCmd () from /usr/lib/libtcl8.4.so.0
> #24 0x406fd6a4 in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so.0
> #25 0x406fe254 in Tcl_EvalEx () from /usr/lib/libtcl8.4.so.0
> #26 0x406fe6eb in Tcl_Eval () from /usr/lib/libtcl8.4.so.0
> #27 0x0805bfac in Ninit (interp=0x807bfb0, w=0x0) at nviz_init.c:459
> #28 0x08051884 in NVIZ_AppInit (interp=0x807bfb0) at nvizAppInit.c:130
> #29 0x40633f94 in Tk_MainEx () from /usr/lib/libtk8.4.so.0
> #30 0x08060f66 in main (argc=3, argv=0xbffff6f4) at nvizMain.c:50
>
> (it failed last year before I was using the radeon card & had dri going...)
>
> still not telling me much. Peppering the C code with printf() and the
> Tcl code with puts, I see that it segfaults while in
> visualization/nviz/scripts/nviz2.2_script
>
> it helped to turn on debug messages (at the top of nviz2.2_script)
> set DEBUG 1
>
>
> segfaults in
> proc Nv_force_panel
> on this line:
> set Nv_($path) [mk$name\Panel $path]
>
> debug output:
> $path=.middle.panelarea.panels.surf
> $name=surf
>
> This is called from the Nv_mkPanelMenu proc, "surf" is the first $i
> of $Nv_(panels).
>
>
> changing that line to
> set Nv_($path) {mk$name\Panel $path}
>
> gets past that SegFault, but then crashes later on. No idea if {that's}
> a correct approach, but it got past the segfault..
>
> Next one: (still in nviz2.2_script)
> it gets to
> proc Nv_mapPanel
>
> and segfaults on this line:
> #insert update to fix KDE wm problem
> update
>
> If I comment out "update", it gets past it, but then segaults again a
> few lines later on "pack $name -side top -fill x -expand no -anchor n",
> or at least a puts after that line never gets displayed.
>
> But on it runs. A window flashes up, I get the "%" prompt on the
> terminal, I get past Ninit() and NVIZ_AppInit(), but lose the
> scent after nviz2.2_script's init_graphics and Nv_expose procs
> finish successfully. (not sure what calls Nv_expose, as it's a bind)
>
>
> further than I got last time anyway.
>
>
>
> Hamish
>
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nv_script.tar
Type: application/x-tar
Size: 30720 bytes
Desc: not available
Url : http://lists.osgeo.org/pipermail/grass-dev/attachments/20060308/fc3d341f/nv_script.tar