[GRASS5] Stars and stripes in raster maps: segfault

Hi,

today we discovered a severe problem in the internal raster resampling
routine. We copied a map (XY location) at lower resolution with r.mapcalc,
the result was a damaged map which crashes various modules.

See screenshots (small) are here
http://mpa.itc.it/markus/tmp/rastercrash/

In details:

GRASS 6.1.cvs (ortoxy):~ > g.region rast="3075" -p
projection: 0 (x,y)
zone: 0
north: 1076
south: 0
west: 0
east: 1082
nsres: 1
ewres: 1
rows: 1076
cols: 1082

GRASS 6.1.cvs (ortoxy):~ > d.rast 3075
-> screenshot "original.jpg" (see URL above)

GRASS 6.1.cvs (ortoxy):~ > g.region rast="3075" res=10

GRASS 6.1.cvs (ortoxy):~ > r.mapcalc '3075_7res="3075"'
100%
GRASS 6.1.cvs (ortoxy):~ > d.rast 3075_7res
*** glibc detected *** free(): invalid next size (normal): 0x09067ab8 ***
Aborted
-> screenshot "damaged_rmapcalc.jpg" see URL above)

r.out.ascii 3075_7res > /dev/null
*** glibc detected *** free(): invalid next size (normal): 0x098f6948 ***
Aborted

gdb `which r.out.ascii`
...
(gdb) bt full
#0 0x003f07a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
No symbol table info available.
#1 0x0029a7d5 in raise () from /lib/tls/libc.so.6
No symbol table info available.
#2 0x0029c149 in abort () from /lib/tls/libc.so.6
No symbol table info available.
#3 0x002ce27a in __libc_message () from /lib/tls/libc.so.6
No symbol table info available.
#4 0x002d4abf in _int_free () from /lib/tls/libc.so.6
No symbol table info available.
#5 0x002d4e3a in free () from /lib/tls/libc.so.6
No symbol table info available.
#6 0x001d7ec0 in close_old (fd=6) at closecell.c:137
        i = 8
#7 0x001d7cac in G_close_cell (fd=6) at closecell.c:82
No locals.
#8 0x08049d2f in main (argc=2, argv=0xbfe56f54) at main.c:202
        out_type = 0
        map_type = 0
        name = 0x8cebc58 "3075_7res"
        mapset = 0x8cebe90 "neteler"
        null_str = 0x804a095 "*"
        surfer_null_str = "1.70141e+038"
        fd = 6
        nrows = 108
        ncols = 108
        dp = 6
        width = 10
        rc = 0
        fp = (FILE *) 0x3985c0
        module = (struct GModule *) 0x21ddcc
        parm = {map = 0x21dd80, output = 0x8ceba70, dp = 0x8cebac0, width = 0x8cebb10, null = 0x8cebb70}
        flag = {noheader = 0x21dd60, surfer = 0x8cebbe0, modflow = 0x8cebc08, int_out = 0x8cebc30}

Using ddd I identified the crash in libgis at:
static int close_old (int fd)
...
  free (FCB.data); <- crash

#6 0x00eddec0 in close_old (fd=7) at closecell.c:137
/hardmnt/thuille0/ssi/software/cvsgrass61/lib/gis/closecell.c:137:3931:beg:0xeddec0

which is called by G_close_cell().

Debugging the d.rast crash, it also crashes in G_close_cell().

We made a test with 6.0 where everything works smoothly. So it seems to be a
recently introduced bug. Or does it have to do with compression? Or size_t?

GRASS 6.1.cvs > pwd
/nfsmnt/mpa_gdata/ssi/BIO/GRASS_DATA/data/ortoxy/cricri/cellhd

cat 3075
proj: 0
zone: 0
north: 1076
south: 0
east: 1082
west: 0
cols: 1082
rows: 1076
e-w resol: 1
n-s resol: 1
format: 0
compressed: 2

Any suggestions?

Markus

Markus Neteler wrote:

today we discovered a severe problem in the internal raster resampling
routine. We copied a map (XY location) at lower resolution with r.mapcalc,
the result was a damaged map which crashes various modules.

Using ddd I identified the crash in libgis at:
static int close_old (int fd)
...
  free (FCB.data); <- crash

If a heap block gets corrupted at some point, it usually manifests
itself when you call free.

The code with the bug won't necessarily be accessing the block which
is corrupted; it could be writing beyond the end of the previous block
and overwriting the header at the start of the block in question.

Often the simplest way to detect such problems is to manually link the
executable against libmcheck and to call mprobe() on the block in
question at regular intervals. The corruption will be occuring between
the last call to mprobe() which succeeded and the first call which
failed.

--
Glynn Clements <glynn@gclements.plus.com>