I have committed r.support to CVS. Give it a whirl.
--
Brad Douglas <rez@touchofmadness.com>
hallo,
r.support is segfaulting
GRASS6.1.cvs(xy):~> r.support --help
Description:
Allows creation and/or modification of raster map layer support files.
Usage:
r.support raster=name
Parameters:
raster Name of input raster
WARNING: Unable to parse arguments.
Description:
Allows creation and/or modification of raster map layer support files.
Usage:
r.support raster=name
Parameters:
raster Name of input raster
Segmentation fault
GRASS6.1.cvs(xy):~>
GRASS GIS compilation log
-------------------------
Started compilation: Èt dub 14 07:04:08 CEST 2005
Errors in:
/usr/src/gis/grass/grass51/raster/r.support/modcats
/usr/src/gis/grass/grass51/raster/r.support/modhist
cd /usr/src/gis/grass/grass51/raster/r.support/modcats
make
Makefile:15: warning: overriding commands for target `htmletc1'
../../../include/Make/Rules.make:94: warning: ignoring old commands for target `htmletc1'
gcc -Wl,--export-dynamic -L/usr/src/gis/grass/grass51/dist.i686-pc-linux-gnu/lib -DPACKAGE=\""grassmods"\" -o /usr/src/gis/grass/grass51/dist.i686-pc-linux-gnu/etc/modcats OBJ.i686-pc-linux-gnu/modcats.o -lgrass_gis -lgrass_datetime -lz -lgrass_edit -lm -lz
/usr/bin/ld: warning: libgrass_vask.so, needed by /usr/src/gis/grass/grass51/dist.i686-pc-linux-gnu/lib/libgrass_edit.so, not found (try using -rpath or -rpath-link)
/usr/src/gis/grass/grass51/dist.i686-pc-linux-gnu/lib/libgrass_edit.so: undefined reference to `V_ques'
/usr/src/gis/grass/grass51/dist.i686-pc-linux-gnu/lib/libgrass_edit.so: undefined reference to `V_line'
/usr/src/gis/grass/grass51/dist.i686-pc-linux-gnu/lib/libgrass_edit.so: undefined reference to `V_call'
/usr/src/gis/grass/grass51/dist.i686-pc-linux-gnu/lib/libgrass_edit.so: undefined reference to `V_intrpt_ok'
/usr/src/gis/grass/grass51/dist.i686-pc-linux-gnu/lib/libgrass_edit.so: undefined reference to `V_const'
/usr/src/gis/grass/grass51/dist.i686-pc-linux-gnu/lib/libgrass_edit.so: undefined reference to `V_clear'
collect2: ld returned 1 exit status
make: *** [/usr/src/gis/grass/grass51/dist.i686-pc-linux-gnu/etc/modcats] Error 1
cd /usr/src/gis/grass/grass51/raster/r.support/modhist
make
Makefile:15: warning: overriding commands for target `htmletc1'
../../../include/Make/Rules.make:94: warning: ignoring old commands for target `htmletc1'
gcc -Wl,--export-dynamic -L/usr/src/gis/grass/grass51/dist.i686-pc-linux-gnu/lib -DPACKAGE=\""grassmods"\" -o /usr/src/gis/grass/grass51/dist.i686-pc-linux-gnu/etc/modhist OBJ.i686-pc-linux-gnu/modhist.o -lgrass_gis -lgrass_datetime -lz -lgrass_edit -lm -lz
/usr/bin/ld: warning: libgrass_vask.so, needed by /usr/src/gis/grass/grass51/dist.i686-pc-linux-gnu/lib/libgrass_edit.so, not found (try using -rpath or -rpath-link)
/usr/src/gis/grass/grass51/dist.i686-pc-linux-gnu/lib/libgrass_edit.so: undefined reference to `V_ques'
/usr/src/gis/grass/grass51/dist.i686-pc-linux-gnu/lib/libgrass_edit.so: undefined reference to `V_line'
/usr/src/gis/grass/grass51/dist.i686-pc-linux-gnu/lib/libgrass_edit.so: undefined reference to `V_call'
/usr/src/gis/grass/grass51/dist.i686-pc-linux-gnu/lib/libgrass_edit.so: undefined reference to `V_intrpt_ok'
/usr/src/gis/grass/grass51/dist.i686-pc-linux-gnu/lib/libgrass_edit.so: undefined reference to `V_const'
/usr/src/gis/grass/grass51/dist.i686-pc-linux-gnu/lib/libgrass_edit.so: undefined reference to `V_clear'
collect2: ld returned 1 exit status
make: *** [/usr/src/gis/grass/grass51/dist.i686-pc-linux-gnu/etc/modhist] Error 1
Jachym
--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://www.fle.czu.cz/~jachym/gnupg_public_key/
On Thu, 2005-04-14 at 07:48 +0200, Jachym Cepicky wrote:
[...]
/usr/bin/ld: warning: libgrass_vask.so, needed by /usr/src/gis/grass/grass51/dist.i686-pc-linux-gnu/lib/libgrass_edit.so, not found (try using -rpath or -rpath-link)
For some reason, your copy of GRASS did not compile/install
libgrass_vask (lib/vask).
--
Brad Douglas <rez@touchofmadness.com>
On Thu, Apr 14, 2005 at 07:57:30AM -0700, Brad Douglas wrote:
On Thu, 2005-04-14 at 07:48 +0200, Jachym Cepicky wrote:
[...]
> /usr/bin/ld: warning: libgrass_vask.so, needed by /usr/src/gis/grass/grass51/dist.i686-pc-linux-gnu/lib/libgrass_edit.so, not found (try using -rpath or -rpath-link)For some reason, your copy of GRASS did not compile/install
libgrass_vask (lib/vask).
Brad,
did you modify lib/vask/? It's not in CVS yet:
http://grass.itc.it/pipermail/grass-commit/2005-April/date.html#end
Markus
On Thu, 2005-04-14 at 17:46 +0200, Markus Neteler wrote:
On Thu, Apr 14, 2005 at 07:57:30AM -0700, Brad Douglas wrote:
> On Thu, 2005-04-14 at 07:48 +0200, Jachym Cepicky wrote:
> [...]
> > /usr/bin/ld: warning: libgrass_vask.so, needed by /usr/src/gis/grass/grass51/dist.i686-pc-linux-gnu/lib/libgrass_edit.so, not found (try using -rpath or -rpath-link)
>
> For some reason, your copy of GRASS did not compile/install
> libgrass_vask (lib/vask).Brad,
did you modify lib/vask/? It's not in CVS yet:
No, I did not modify vask. r.support works for you, right? I imported
into a clean tree and everything works fine for me.
--
Brad Douglas <rez@touchofmadness.com>
On Thu, Apr 14, 2005 at 01:53:51PM -0700, Brad Douglas wrote:
On Thu, 2005-04-14 at 17:46 +0200, Markus Neteler wrote:
> On Thu, Apr 14, 2005 at 07:57:30AM -0700, Brad Douglas wrote:
> > On Thu, 2005-04-14 at 07:48 +0200, Jachym Cepicky wrote:
> > [...]
> > > /usr/bin/ld: warning: libgrass_vask.so, needed by /usr/src/gis/grass/grass51/dist.i686-pc-linux-gnu/lib/libgrass_edit.so, not found (try using -rpath or -rpath-link)
> >
> > For some reason, your copy of GRASS did not compile/install
> > libgrass_vask (lib/vask).
>
> Brad,
> did you modify lib/vask/? It's not in CVS yet:No, I did not modify vask. r.support works for you, right? I imported
into a clean tree and everything works fine for me.
Unfortunately I also get a segfault...
gdb `which r.support`
r -h
[...]
Program received signal SIGSEGV, Segmentation fault.
0x0012dda9 in G__find_file (element=0x15ee9c "cell", name=0x0, mapset=0x804a495 "")
at find_file.c:43
43 if (*name == 0)
(gdb) bt
#0 0x0012dda9 in G__find_file (element=0x15ee9c "cell", name=0x0, mapset=0x804a495 "")
at find_file.c:43
#1 0x0012dfea in G_find_file (element=0x15ee9c "cell", name=0x0, mapset=0x804a495 "")
at find_file.c:115
#2 0x0012dd58 in G_find_cell (name=0x0, mapset=0x804a495 "") at find_cell.c:64
#3 0x08049919 in main (argc=2, argv=0xbfff8a64) at front.c:62
A string issue? Maybe something like this is better (from r.univar2):
mapset = G_find_cell2 (infile, "");
if (mapset == NULL)
G_fatal_error(_("raster <%s> not found"), infile);
Markus
On Thu, Apr 14, 2005 at 09:22:57PM -0700, Brad Douglas wrote:
...
Let me know if you are still having trouble. I believe it's a null
dereference in G__find_file(). I just pointed a pointer to it, which
should stop the segfault.I've tried it again and again with all option combinations and I still
fail to crash. Odd.
It still crashed, but I have applied this fix to CVS:
front.c:
/* Parse command-line options */
- if (G_parser(argc, argv)) {
- G_warning(_("Unable to parse arguments."));
- G_usage();
- }
+ if (G_parser(argc,argv))
+ exit(1);
I remember darkly that G_usage() should not be used any more.
The old code was from 5.x...
Now it works.
Markus
On Fri, 2005-04-15 at 10:36 +0200, Markus Neteler wrote:
On Thu, Apr 14, 2005 at 09:22:57PM -0700, Brad Douglas wrote:
...
> Let me know if you are still having trouble. I believe it's a null
> dereference in G__find_file(). I just pointed a pointer to it, which
> should stop the segfault.
>
> I've tried it again and again with all option combinations and I still
> fail to crash. Odd.It still crashed, but I have applied this fix to CVS:
front.c:
/* Parse command-line options */
- if (G_parser(argc, argv)) {
- G_warning(_("Unable to parse arguments."));
- G_usage();
- }
+ if (G_parser(argc,argv))
+ exit(1);I remember darkly that G_usage() should not be used any more.
The old code was from 5.x...
G_usage() is depreciated? Even so, the above changes should not fix the
module.
Did G_parser() somehow succeed without command-line arguments before
this patch was applied (and why for you and not for me?)? That would
explain how G__find_file() was segfaulting on a null pointer
dereference.
This is very strange.
--
Brad Douglas <rez@touchofmadness.com>