[GRASS5] Tcl8.4 support?

Glynn Clements glynn.clements at virgin.net
Fri Aug 29 02:26:06 EDT 2003


Hamish wrote:

> > > > > The CVS HEAD version of NVIZ still doesn't work on Debian Testing
> > > > > with tcl8.4.
> > > ...
> > > > > (gets stuck on "exec")
> > > ...
> > > > could you add some "strace" into etc/nviz2.2/scripts/nviz2.2_script
> > > > to debug the binary problem and send the outcome (at least the
> > > > crashing part)?
> ...
> > You would need to use "strace -f ..." to trace child processes. Only
> > tracing the top-level process won't tell you very much.
> 
> 
> Ok, here is the full log:
> http://bambi.otago.ac.nz/hamish/grass/strace-f_nviz_tcl8.4.txt.gz

In retrospect, even tracing the child process won't normally tell you
much about what caused a segfault. Sometimes it may provide a clue,
e.g. if a system call failed immediately before the segfault, that's
often an indication that the code doesn't allow for the call failing. 
But in most cases, the segfault is unrelated to system calls.

If the process generated a core file, use a debugger to examine it;
otherwise, you would have to run NVIZ under a debugger.

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

> Here's the bit with the SegFault:   old_mmap() / munmap() ?

old_mmap(..., MAP_PRIVATE|MAP_ANONYMOUS, ...) is one of the ways in
which malloc() gets more memory from the system. A call to munmap()
with the address returned from old_mmap() corresponds to that memory
having been freed. I doubt that this has anything to do with the
segfault; more likely, the mmap() call just happened to the last thing
before the crash.

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




More information about the grass-dev mailing list