Sat, Jun 28 2003
14:24:16
|
|
Request created by guest
|
|
Subject: r.fill.dir segfaults
Platform: GNU/Linux/i386
grass obtained from: CVS
grass binary for platform: Compiled from Sources
GRASS Version: release_10_04_2003_grass5_0_2 and CVS HEAD
AS reported on the devel-list, here is the bug-report.
reproducable in Spearfish-data:
with floating-point grid
GRASS:~ > r.fill.dir in=elev.float elev=blah dir=dir
Reading map...
Filling sinks...
Determining flow directions for ambiguous cases...
Downward pass 1
Upward pass 1
Downward pass 2
Upward pass 2
Downward pass 3
Found 1897 unresolved areas
wtrshed pass 1
wtrshed pass 2
wtrshed pass 3
wtrshed pass 4
wtrshed pass 5
Speicherzugriffsfehler [segmentation fault]
GRASS:~ >
with integer grid
r.fill.dir in=elevation.dem elev=blah dir=dir
Reading map...
Filling sinks...
Determining flow directions for ambiguous cases...
Downward pass 1
Upward pass 1
Downward pass 2
Upward pass 2
Downward pass 3
Found 1895 unresolved areas
wtrshed pass 1
wtrshed pass 2
wtrshed pass 3
wtrshed pass 4
wtrshed pass 5
Speicherzugriffsfehler [segmentation fault]
GRASS:~ >
Markus found out the following:
<markus>
read mor in: Message-ID: <20030626111418.A20397@itc.it>
The bug appears in get_min() which is called in
raster/r.fill.dir/ppupdate.c
row 134
The second parameter to get_min() seems to be empty when
it crashes.
</markus>
the whole thread can be found under
Message-Id: <20030626083947.35dc769f.sholl@gmx.net>
A sample location to reproduce this is packaged here:
www.8ung.at/stephn.holl/tmp/sample_r.fill.dir_bug.tgz (1,2 MB)
Stephan Holl |
|
Sat, Aug 9 2003
09:19:12
|
|
Comments added by hbowman
|
|
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:~ >
|
|
Sat, Aug 9 2003
11:01:37
|
|
Mail sent by glynn.clements@virgin.net
|
|
Return-Path |
<glynn.clements@virgin.net>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
From |
Glynn Clements <glynn.clements@virgin.net>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Transfer-Encoding |
7bit
|
Message-ID |
<16180.47208.415255.767743@cerise.nosuchdomain.co.uk>
|
Date |
Sat, 9 Aug 2003 10:01:28 +0100
|
To |
Harmisch Bowman via RT <grass-bugs@intevation.de>
|
Cc |
grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #1969] (grass) bug 1969: r.fill.dir segfaults
|
In-Reply-To |
<20030809071913.1422513B55@lists.intevation.de>
|
References |
<20030809071913.1422513B55@lists.intevation.de>
|
X-Mailer |
VM 7.07 under 21.4 (patch 13) "Rational FORTRAN" XEmacs Lucid
|
X-Spam-Status |
No, hits=-2.5 required=5.0 tests=EMAIL_ATTRIBUTION,IN_REP_TO,QUOTED_EMAIL_TEXT,REFERENCES, REPLY_WITH_QUOTES version=2.55
|
X-Spam-Level |
|
X-Spam-Checker-Version |
SpamAssassin 2.55 (1.174.2.19-2003-05-19-exp) |
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>
|
|
Wed, Aug 13 2003
02:07:29
|
|
Comments added by hbowman
|
|
Ok, the fix is now in CVS.
Could someone test it before closing the bug? (Stephan?)
|
|
Wed, Aug 13 2003
18:39:27
|
|
Mail sent by guest
|
|
Success reported by Stephan.
Thanks to Hamish!
Markus
|
|
Wed, Aug 20 2003
16:24:30
|
|
Status changed to resolved by mneteler
|
|