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

Scott W Mitchell smitch at mac.com
Fri May 2 13:23:18 EDT 2003


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 at 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




More information about the grass-dev mailing list