this bug's URL: http://intevation.de/rt/webrt?serial_num=1969
Request number 1969 was commented on by 'hbowman' (Harmisch Bowman).
Responding to this message will send mail to the requestor.
Request Tracker
rt@intevation.de
--------------------------------------------------------------
Cc: grass5@grass.itc.it
[bug 1969]
doing a dumb debug, just populating grass/src/raster/r.fill.dir/ppupdate.c
with some printf()'s, the SegFault happens for me during the G_free(list) call.
call added here:
http://freegis.org/cgi-bin/viewcvs.cgi/grass/src/raster/r.fill.dir/ppupdate.c.diff?r1=1.2&r2=1.3
$ tail ppupdate.c
memcpy(this_elev,get_max(this_elev,list[ii].pp),bpe());
}
lseek(fe,-elev->sz,SEEK_CUR);
write(fe,elev->b[1],elev->sz);
}
printf("end of fill\n");
G_free(list);
printf("end of ppupdate\n");
}
GRASS:~ > r.fill.dir in=bathy elev=rfd_el dir=rfd_dir areas=rfd_err
[...]
end of looking for pairs
end of backtrace
end of fill
Segmentation fault
GRASS:~ >
-------------------------------------------- Managed by Request Tracker
Harmisch Bowman via RT wrote:
this bug's URL: http://intevation.de/rt/webrt?serial_num=1969
Request number 1969 was commented on by 'hbowman' (Harmisch Bowman).
Responding to this message will send mail to the requestor.
Request Tracker
rt@intevation.de
--------------------------------------------------------------
Cc: grass5@grass.itc.it
[bug 1969]
doing a dumb debug, just populating grass/src/raster/r.fill.dir/ppupdate.c
with some printf()'s, the SegFault happens for me during the G_free(list) call.
list = G_malloc(nbasins * sizeof(struct links));
for(i=1;i<=nbasins;i+=1)
{
list[i].next=-1;
The code overruns the array. If you want to access list[nbasins], you
have to allocate nbasins+1 elements. For an N-element array, the valid
indices are 0 to N-1 inclusive; element N is not valid.
Note that the old version also overran the array. However, the old
version had the array on the stack, where you are more likely to get
away with an overrun (although list[nbasins] will be trashed by
function calls, writing to it won't usually cause problems).
Overrunning a heap block tends to result in segfault in a later
(sometimes much later) call to malloc(), free() etc. At least, that's
the case for GNU malloc(), which stores metadata at the start of the
block; BSD's malloc() stores metadata in separate areas, so you just
overrun into the next data block rather than into metadata.
--
Glynn Clements <glynn.clements@virgin.net>