[GRASS5] Tcl8.4 support?

Helena hmitaso at unity.ncsu.edu
Sun Sep 14 12:28:50 EDT 2003 

Hamish wrote:

> Turns out the raster I was testing NVIZ out with is a CELL map.
> Tried to run nviz on an integer based raster on a RedHat install & it
> gave the same SegFault.
> So NVIZ doesn't like integer based maps.

Hamish I have been using nviz with CELL maps with no problems (e.g. figs 
5.1b,6.8a,7.2a in the book) and I tried it with the recent nviz version 
from CVS right now and it runs OK too.

> It also fails with pages of errors if there is no data in the
> current region (d.zoom to an all null part of the map).

yes, it crashes if one tries to display a map that is out of the given 
region - it obviously tries to compute some of the initial variables 
that is undefined - I got this error (it looks like something for the 
cutting plane pannel):

Error in startup script: integer value too large to represent
     while executing
"expr int([lindex $range 1])"
     (procedure "mkcutplanePanel" line 55)
     invoked from within
"mk$name\Panel $path"
     (procedure "Nv_force_panel" line 10)
     invoked from within

Helena
....
> 
> If these will always fail, checks early on & a graceful exit with
> useful error messages would be better..
> 
> So that explains the SegFault anyway.
> 
> -----
> 
> But back to Debian with TclTk 8.4 and the bug as reported in
> http://article.gmane.org/gmane.comp.gis.grass.devel/1883
> 
> "it does freeze up (0% cpu) at the first instance of "exec"
> in etc/nviz2.2/scripts/nviz2.2_script, line 78:   (Adding panels section)
>     set panels [exec cat $index]
> 
> (I tried placing some exec's further up in the script & they did the
> same lock-up)"
> 
> sample run:
> GRASS:~ > nviz raster_dem
> [...]
> The papers are available at
> http://www2.gis.uiuc.edu:2280/modviz/
> Loading Data
> Loading Data
> translating colors from fp
> Adding panels from /usr/src/grass5source/grass-5.0.3rc3/dist.i686-pc-linux-gnu/etc/nviz2.2/scripts
> 
> and then it just sits there using 0% cpu with the "Please Wait.." window up.
> 
> 
> strace -f ends with looping getppid() every 2 seconds or so:
> [...]
> Process 7403 detached
> [pid  7402] close(14)                   = 0
> [pid  7402] read(13,  <unfinished ...>
> [pid  7397] <... poll resumed> [{fd=3, events=POLLIN}], 1, 2000) = 0
> [pid  7397] getppid()                   = 7396
> [pid  7397] poll([{fd=3, events=POLLIN}], 1, 2000) = 0
> [pid  7397] getppid()                   = 7396
> [pid  7397] poll([{fd=3, events=POLLIN}], 1, 2000) = 0
> [pid  7397] getppid()                   = 7396
> [pid  7397] poll([{fd=3, events=POLLIN}], 1, 2000) = 0
> [pid  7397] getppid()                   = 7396
> [pid  7397] poll([{fd=3, events=POLLIN}], 1, 2000) = 0
> [pid  7397] getppid()                   = 7396
> [pid  7397] poll([{fd=3, events=POLLIN}], 1, 2000) = 0
> [etc...]
> until I kill it.
> 
> full log here:
>   http://bambi.otago.ac.nz/hamish/grass/strace-f_nviz.log.gz
> 
> 
> Running gdb, then ^Z when it gets stuck:
> 
> GRASS:./grass-5.0.3rc3 > gdb dist.i686-pc-linux-gnu/etc/nviz2.2/NVWISH2.2 GNU gdb 5.3-debian
> Copyright 2002 Free Software Foundation, Inc.
> [...]
> (gdb) run -f dist.i686-pc-linux-gnu/etc/nviz2.2/scripts/nviz2.2_script -name NVIZ
> [...]
> Enter the name of an existing Raster file
> Enter 'list' for a list of existing Raster files
> Hit RETURN to cancel request
> 
>>raster_dem
> 
> [...]
> The papers are available at
> http://www2.gis.uiuc.edu:2280/modviz/
> Loading Data
> Loading Data
> translating colors from fp
> Adding panels from /usr/src/grass5source/grass-5.0.3rc3/dist.i686-pc-linux-gnu/etc/nviz2.2/scripts
> 
> [<wait> Ctrl-Z]
> (no debugging symbols found)...(no debugging symbols found)...
> Program received signal SIGTSTP, Stopped (user).
> [Switching to Thread 16384 (LWP 7482)]
> 0x4049ba54 in read () from /lib/libc.so.6
> (gdb) bt
> #0  0x4049ba54 in read () from /lib/libc.so.6
> #1  0x401b3004 in _LIB_VERSION () from /usr/lib/libtcl8.4.so.0
> #2  0x4018193f in TclCreatePipeline () from /usr/lib/libtcl8.4.so.0
> #3  0x40182195 in Tcl_OpenCommandChannel () from /usr/lib/libtcl8.4.so.0
> #4  0x4016ee7a in Tcl_ExecObjCmd () from /usr/lib/libtcl8.4.so.0
> #5  0x40136646 in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so.0
> #6  0x401594a2 in TclCompEvalObj () from /usr/lib/libtcl8.4.so.0
> #7  0x40158adc in TclCompEvalObj () from /usr/lib/libtcl8.4.so.0
> #8  0x4013764d in Tcl_EvalObjEx () from /usr/lib/libtcl8.4.so.0
> #9  0x4013ce8c in Tcl_ForeachObjCmd () from /usr/lib/libtcl8.4.so.0
> #10 0x40136646 in TclEvalObjvInternal () from /usr/lib/libtcl8.4.so.0
> #11 0x4013707c in Tcl_EvalEx () from /usr/lib/libtcl8.4.so.0
> #12 0x40171aa6 in Tcl_FSEvalFile () from /usr/lib/libtcl8.4.so.0
> #13 0x40170c2a in Tcl_EvalFile () from /usr/lib/libtcl8.4.so.0
> #14 0x400824a9 in Tk_MainEx () from /usr/lib/libtk8.4.so.0
> #15 0x080573bc in strcpy ()
> #16 0x403f9a51 in __libc_start_main () from /lib/libc.so.6
> (gdb) info f
> Stack level 0, frame at 0xbfffea98:
>  eip = 0x4049ba54 in read; saved eip 0x4018193f
>  (FRAMELESS), called by frame at 0xbfffea98
>  Arglist at 0xbfffea98, args: 
>  Locals at 0xbfffea98, Previous frame's sp in esp
>  Saved registers:
>   ebp at 0xbfffea98, eip at 0xbfffea9c
> (gdb) l
> No symbol table is loaded.  Use the "file" command.
> (gdb) info args
> No symbol table info available.
> (gdb) info locals
> No symbol table info available.
> (gdb) quit
> A debugging session is active.
> Do you still want to close the debugger?(y or n) y
> GRASS:/usr/src/grass5source/grass-5.0.3rc3 > 
> 
> 
> I'll (re)confirm Tcl/Tk 8.3 doesn't show this behavior tomorrow.
> 
> 
> still confused, but slightly less so,
> Hamish
> 
> 
> -------------------------------------------
> old business:
> 
> 
>>>>AFAICT from the error message, it's the core NVIZ process which
>>>>crashed; i.e. not the "nviz" script, but the NVWISH2.2 binary
>>>>interpreting nviz2.2_script. To debug that, you would need to
>>>>emulate the "nviz" script by setting up the various environment
>>>>variables, then running NVWISH2.2 under gdb, e.g.:
>>>>
>>>>	export GISDBASE=`g.gisenv get=GISDBASE`
>>>>	export LOCATION_NAME=`g.gisenv get=LOCATION_NAME`
>>>>	export MAPSET=`g.gisenv get=MAPSET`
>>>>	gdb /usr/local/grass5/etc/nviz2.2/NVWISH2.2
>>>>	> run -f /usr/local/grass5/etc/nviz2.2/scripts/nviz2.2_script
>>>>	> -name NVIZ
> 
> ...
> 
>>>I'm new to gdb, bear with me. 
>>>   -How to turn on debugging symbols?
>>>   -How to set up symbol tables info? [(gdb) bt f]
>>>      "No symbol table info available."
>>
>>Odd. Has the NVWISH2.2 binary been stripped?
> 
> 
> Nope. At least not by me at the command line.
> 
> 
> 
>>>note NVIZ is printing "Version: @(#) 5.0.2 (April 2003)" before 
>>>the copyright notice..?
>>
>>That suggests that either configure hasn't been re-run since the last
>>update, or NVIZ hasn't been re-built (forgot to run "make distclean"
>>first), or that NVIZ failed to compile and the old version is still in
>>place (forgot to "rm -rf /usr/local/grass5" before "make install").
> 
> 
> That was a mistake on my part. I hadn't installed with 'make install', I
> was running GRASS from bin.i686-pc-linux-gnu/grass5. I then told gdb to
> run NVIZ from /usr/local/grass5, which was 5.0.2.. A 'make uninstall'
> later and a fresh compile of 5.0.3rc3 directly from the tarball gives
> the same SegFault & gdb session though [turns out that was the CELL map].
> 
> 
> Where do you change the Makefiles to have GRASS compile with "gcc-2.95"
> instead of"gcc" (ie gcc-3.3) ?
> 
> 
> 
>>>Program received signal SIGSEGV, Segmentation fault.
>>>[Switching to Thread 16384 (LWP 5725)]
>>>0x4042452d in vfprintf () from /lib/libc.so.6
>>>(gdb)  bt
>>>#0  0x4042452d in vfprintf () from /lib/libc.so.6
>>>#1  0x4043d386 in vsprintf () from /lib/libc.so.6
>>>#2  0x4042c21a in sprintf () from /lib/libc.so.6
>>>#3  0x0808edd1 in strcpy ()
>>>#4  0x0805c2f8 in strcpy ()
>>>#5  0x08052424 in strcpy ()
>>>#6  0x080506a1 in strcpy ()
>>>#7  0x401357ff in TclInvokeStringCommand () from
>>>/usr/lib/libtcl8.4.so.0#8  0x40136646 in TclEvalObjvInternal () from
>>>/usr/lib/libtcl8.4.so.0#9  0x4013707c in Tcl_EvalEx () from
>>>/usr/lib/libtcl8.4.so.0#10 0x40137495 in Tcl_Eval () from
>>>/usr/lib/libtcl8.4.so.0#11 0x401387d3 in Tcl_VarEvalVA () from
>>>/usr/lib/libtcl8.4.so.0#12 0x40138807 in Tcl_VarEval () from
>>>/usr/lib/libtcl8.4.so.0#13 0x080536d7 in strcpy ()
>>>#14 0x08053bc2 in strcpy ()
>>>#15 0x0804c207 in strcpy ()
>>>#16 0x40082452 in Tk_MainEx () from /usr/lib/libtk8.4.so.0
>>>#17 0x0805749c in strcpy ()
>>>#18 0x403f6a51 in __libc_start_main () from /lib/libc.so.6
>>
>>If tcltkgrass is crashing inside "pure" Tcl/Tk code, you won't be able
>>to find out much unless you have a version of libtcl which has debug
>>info.
> 
> 
> I think (could be wrong) Debian binaries are stripped by default.
> 
> _______________________________________________
> grass5 mailing list
> grass5 at grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5

More information about the grass-dev mailing list