[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