[GRASS5] problem with G_get_null_value_row &/or mapset searches in my own program

Greetings,

I am porting a program written for GRASS4 to "the modern age". After dealing with a mess of code for a long time, I decided to start largely from scratch, replacing relevant functions with new ones from the GRASS5 API.

It was going pretty well, I got floating point support working, and decided it was time to tackle the NULL data issue (the previous program just checked for zeros in the input and ignored them).

The original program reads the whole raster into memory and samples all over this array to gather a bunch of statistics. I decided to keep this behaviour, since it would be quite awkward to use row-based processing for the algorithm in question. But I figured I could use G_get_null_value_row to hold a row's worth of data on null/non-null for the one place in the algorithm where this would be useful.

The trouble is, my program core dumps as soon as it gets to
G_get_null_value_row(fd, nullbuf, r);

I've compared my program to others in the source tree, and as far as I can see I am using it identically. So I got it into a debugger and found that the core dump is actually happening "further in", when G_get_cell_hd calls G_is_reclass ... and the arguments in that function call reminded me of another unresolved bug I hadn't got to yet in this software, which is probably my real problem here.

This other problem is that I've done something wrong, or am missing something important, which is interfering with the module's ability to find files - or maybe it's the ability to keep track of the current mapset. As part of my rewrite of this program, I got rid of the user interface it had and used the G_parser routines. I find now that if I give all my arguments on the command line, it seems to start off just fine, and prior to my attempts to support NULL data, it proceeded through to the end of the program, finding all the input it needed and creating output. But if I tried to use the interactive version (through G_parser's assistance), any parameters that were looking for existing files (rasters and site_lists) in the database could not be found - and typing "list" in response to the prompt always returned an empty list.

SO - sounds to me like the mapset is "lost", and I don't know why. As far as I can see I've followed the conventions in r.example and other "real" programs. I declare my variables, call G_gisinit(), declare all my parameter and flag structures, and call G_parser. All other programs I've tried from the distributed source are behaving normally (using CVS HEAD, aka grass 5.0.3-cvs).

I'm hoping this will be some simple, silly, error that will sound familiar to those of you experienced in writing GRASS modules.... anyone ?

Thanks

------
Scott W. Mitchell smitch@geog.utoronto.ca
Department of Geography Phone: (613) 730-5375
University of Toronto at Mississauga UTM fax: (905) 828-5273
3359 Mississauga Road Local fax (613) 822-5143
Mississauga, ON L5L 1C6 Canada

Scott W Mitchell wrote:

I am porting a program written for GRASS4 to "the modern age". After
dealing with a mess of code for a long time, I decided to start largely
from scratch, replacing relevant functions with new ones from the
GRASS5 API.

It was going pretty well, I got floating point support working, and
decided it was time to tackle the NULL data issue (the previous program
just checked for zeros in the input and ignored them).

The original program reads the whole raster into memory and samples all
over this array to gather a bunch of statistics. I decided to keep
this behaviour, since it would be quite awkward to use row-based
processing for the algorithm in question. But I figured I could use
G_get_null_value_row to hold a row's worth of data on null/non-null for
the one place in the algorithm where this would be useful.

The trouble is, my program core dumps as soon as it gets to
G_get_null_value_row(fd, nullbuf, r);

I wouldn't recommend calling that directly; it would be safer to just
scan the data obtained by G_get_*_raster_row() etc for nulls.

I've compared my program to others in the source tree, and as far as I
can see I am using it identically. So I got it into a debugger and
found that the core dump is actually happening "further in", when
G_get_cell_hd calls G_is_reclass ...

I don't see how G_get_null_value_row() can end up calling
G_get_cellhd().

and the arguments in that function
call reminded me of another unresolved bug I hadn't got to yet in this
software, which is probably my real problem here.
This other problem is that I've done something wrong, or am missing
something important, which is interfering with the module's ability to
find files - or maybe it's the ability to keep track of the current
mapset. As part of my rewrite of this program, I got rid of the user
interface it had and used the G_parser routines. I find now that if I
give all my arguments on the command line, it seems to start off just
fine, and prior to my attempts to support NULL data, it proceeded
through to the end of the program, finding all the input it needed and
creating output. But if I tried to use the interactive version
(through G_parser's assistance), any parameters that were looking for
existing files (rasters and site_lists) in the database could not be
found - and typing "list" in response to the prompt always returned an
empty list.

SO - sounds to me like the mapset is "lost", and I don't know why. As
far as I can see I've followed the conventions in r.example and other
"real" programs. I declare my variables, call G_gisinit(), declare all
my parameter and flag structures, and call G_parser. All other
programs I've tried from the distributed source are behaving normally
(using CVS HEAD, aka grass 5.0.3-cvs).

I'm hoping this will be some simple, silly, error that will sound
familiar to those of you experienced in writing GRASS modules....
anyone ?

No; I don't know of any obvious reason why you might have that
problem.

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

On Sat, 3 May 2003, Glynn Clements wrote:

Scott W Mitchell wrote:

> I've compared my program to others in the source tree, and as far as I
> can see I am using it identically. So I got it into a debugger and
> found that the core dump is actually happening "further in", when
> G_get_cell_hd calls G_is_reclass ...

I don't see how G_get_null_value_row() can end up calling
G_get_cellhd().

As far as I can see using cflow (an old but trusted utility for printing a
graph of a function's call hierarchy) G_get_null_value_row() does not call
G_get_cellhd(), nor do any of the functions called by it all the way
through its call hierarchy.

Although this isn't relevant here, Markus did ask me to remind him about
cflow, which, since it comes from the same era as much of the code (at
least in libes/gis), does show what is calling what, or what is called by
what if inverted.

Roger

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand@nhh.no

cflow sounds like a good tool to know about, thanks. I hadn't got to checking whether or not those functions were even called.

My guess is that I've abused a pointer somewhere, or am somehow else tramping on memory, leading to a misleading error.

I'll have to comb through my assignments looking for mistakes.

Thanks...

Scott

On Saturday, May 3, 2003, at 04:29 Canada/Eastern, Roger Bivand wrote:

On Sat, 3 May 2003, Glynn Clements wrote:

Scott W Mitchell wrote:

I've compared my program to others in the source tree, and as far as I
can see I am using it identically. So I got it into a debugger and
found that the core dump is actually happening "further in", when
G_get_cell_hd calls G_is_reclass ...

I don't see how G_get_null_value_row() can end up calling
G_get_cellhd().

As far as I can see using cflow (an old but trusted utility for printing a
graph of a function's call hierarchy) G_get_null_value_row() does not call
G_get_cellhd(), nor do any of the functions called by it all the way
through its call hierarchy.

Although this isn't relevant here, Markus did ask me to remind him about
cflow, which, since it comes from the same era as much of the code (at
least in libes/gis), does show what is calling what, or what is called by
what if inverted.

Roger

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand@nhh.no

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

------
Scott W. Mitchell smitch@geog.utoronto.ca
Department of Geography Phone: (613) 730-5375
University of Toronto at Mississauga UTM fax: (905) 828-5273
3359 Mississauga Road Local fax (613) 822-5143
Mississauga, ON L5L 1C6 Canada

On Sat, 3 May 2003, Scott W Mitchell wrote:

cflow sounds like a good tool to know about, thanks. I hadn't got to
checking whether or not those functions were even called.

Reading thousands of lines of code is easier for a computer!

My guess is that I've abused a pointer somewhere, or am somehow else
tramping on memory, leading to a misleading error.

Electric Fence, maybe? Or another tool to try to help find memory bugs?
They are tiresome, everybody has them, keep trying!

I'll have to comb through my assignments looking for mistakes.

Thanks...

Scott

On Saturday, May 3, 2003, at 04:29 Canada/Eastern, Roger Bivand wrote:

> On Sat, 3 May 2003, Glynn Clements wrote:
>
>>
>> Scott W Mitchell wrote:
>>
>>
>>> I've compared my program to others in the source tree, and as far as
>>> I
>>> can see I am using it identically. So I got it into a debugger and
>>> found that the core dump is actually happening "further in", when
>>> G_get_cell_hd calls G_is_reclass ...
>>
>> I don't see how G_get_null_value_row() can end up calling
>> G_get_cellhd().
>
> As far as I can see using cflow (an old but trusted utility for
> printing a
> graph of a function's call hierarchy) G_get_null_value_row() does not
> call
> G_get_cellhd(), nor do any of the functions called by it all the way
> through its call hierarchy.
>
> Although this isn't relevant here, Markus did ask me to remind him
> about
> cflow, which, since it comes from the same era as much of the code (at
> least in libes/gis), does show what is calling what, or what is called
> by
> what if inverted.
>
> Roger
>
> --
> Roger Bivand
> Economic Geography Section, Department of Economics, Norwegian School
> of
> Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
> Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
> e-mail: Roger.Bivand@nhh.no
>
> _______________________________________________
> grass5 mailing list
> grass5@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grass5
>
------
Scott W. Mitchell smitch@geog.utoronto.ca
Department of Geography Phone: (613) 730-5375
University of Toronto at Mississauga UTM fax: (905) 828-5273
3359 Mississauga Road Local fax (613) 822-5143
Mississauga, ON L5L 1C6 Canada

--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Breiviksveien 40, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 93 93
e-mail: Roger.Bivand@nhh.no

On Sat, May 03, 2003 at 10:29:06AM +0200, Roger Bivand wrote:
[...]

As far as I can see using cflow (an old but trusted utility for printing a
graph of a function's call hierarchy) G_get_null_value_row() does not call
G_get_cellhd(), nor do any of the functions called by it all the way
through its call hierarchy.

Although this isn't relevant here, Markus did ask me to remind him about
cflow, which, since it comes from the same era as much of the code (at
least in libes/gis), does show what is calling what, or what is called by
what if inverted.

The code of CFLOW is here:
http://packages.qa.debian.org/c/cflow.html
(get the original package and the patches)

As a dependency also get:
http://packages.debian.org/stable/base/debianutils.html
(you need to install only 'tempfile' from that package as far as I remember).

Then run
cflow file.c

Thanks for the hint, Roger,

Markus