[GRASS-user] bug in r.pi.nlm add-on module

Martin Wegmann wegmann2011 at googlemail.com
Mon Feb 6 08:25:50 EST 2012


On Wednesday, February 01, 2012 14:06:49 Hamish wrote:
> Martin Wegmann wrote:
> > > I encountered a bug in an add-on module, r.pi.nlm
> > 
> > ...
> > 
> > > (gdb) r.pi.nlm input=landclass96 keyval=5 output=test
> > 
> > --o
> > 
> > > Starting program:
> > ...
> > 
> > > Program received signal SIGSEGV, Segmentation fault.
> > 
> > ...
> > 
> > > (gdb) bt full
> > 
> > ...
> > 
> > >         min = 1000000
> > >         max = 1000000
> > >
> > >         span = 0
> > 
> > ...
> > 
> > >         index = -2147483648
> > 
> > ...
> > 
> > > in func.c:
> > ...
> > 
> > >     span = max - min;
> > >     c = min / span;
> > 
> > ...
> > 
> > >         index = floor(RESOLUTION *
> > > (map[i] - min) / span);
> > >         ^^^^^^--- negative
> > > 
> > >     Then the subsequent values[index] crashes.
> > 
> > min=max so span=0. the resulting divide by 0
> > causes the index to go to infinity.
> 
> I notice MinMax() in func.c starts its for loop
> at i=1 instead of 0, perhaps that is a bug?

I changed i=0 but no changes.

we checked the min, max and size values, and something seems to be wrong with 
them:

in func.c added in CutValues:

..
    // get parameters
    MinMax(map, &min, &max, size);
    //added check if min<max
   if (max<=min)
   	G_fatal_error(_("Error in CutValues! Min ge to max. Min is: <%d>.Max is: 
<%d>.Size is: <%i>. "), min, max, size);	

results in:
ERROR: Error in CutValues! Min ge to max. Min is: <16641>.Max is: <0>.Size
       is: <0>.

However, we did not understand why this happens.

BTW the module used to work quite a while ago - anything changed in the last 
year which might have caused this - c memory handling etc.?

Martin





More information about the grass-user mailing list