[GRASS-dev] r.in.xyz: *** glibc detected *** double free or corruption

GRASS GIS GRASS GIS developer
1

Although I seem to now be able to *open* large files with r.in.xyz, it
inevitably crash about 15 minutes into the gridding of a 2.8GB xyz file,
every time.

Here's the output from gdb:

(gdb) r.in.xyz input=2006MB_GarryTrough_2.txt output=2006MB_GarryTrough_2
fs=space
Starting program: /opt/grass6/dist.i686-pc-linux-gnu/bin/r.in.xyz .in.xyz
input=2006MB_GarryTrough_2.txt output=2006MB_GarryTrough_2 fs=space
Scanning data ...
*** glibc detected *** double free or corruption (fasttop): 0x0804e2c8 ***

Program received signal SIGABRT, Aborted.
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7d959a1 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7d972b9 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0xb7dc987a in __fsetlocking () from /lib/tls/i686/cmov/libc.so.6
#4 0xb7dcffd4 in malloc_usable_size () from /lib/tls/i686/cmov/libc.so.6
#5 0xb7dd034a in free () from /lib/tls/i686/cmov/libc.so.6
#6 0xb7f0293a in G_free (buf=0x0) at alloc.c:104
#7 0xb7f2eb03 in G_free_tokens (tokens=0x4b) at token.c:68
#8 0x0804a706 in main (argc=0, argv=0xbf952fa4) at main.c:468
(gdb)

I may need some pointers on using gdb, as this is my first time. But
hopefully this backtrace will be useful.

~ Eric.

2

Patton, Eric wrote:

Although I seem to now be able to *open* large files with r.in.xyz, it
inevitably crash about 15 minutes into the gridding of a 2.8GB xyz file,
every time.

Here's the output from gdb:

(gdb) r.in.xyz input=2006MB_GarryTrough_2.txt output=2006MB_GarryTrough_2
fs=space
Starting program: /opt/grass6/dist.i686-pc-linux-gnu/bin/r.in.xyz .in.xyz
input=2006MB_GarryTrough_2.txt output=2006MB_GarryTrough_2 fs=space
Scanning data ...
*** glibc detected *** double free or corruption (fasttop): 0x0804e2c8 ***

Program received signal SIGABRT, Aborted.
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7d959a1 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7d972b9 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0xb7dc987a in __fsetlocking () from /lib/tls/i686/cmov/libc.so.6
#4 0xb7dcffd4 in malloc_usable_size () from /lib/tls/i686/cmov/libc.so.6
#5 0xb7dd034a in free () from /lib/tls/i686/cmov/libc.so.6
#6 0xb7f0293a in G_free (buf=0x0) at alloc.c:104
#7 0xb7f2eb03 in G_free_tokens (tokens=0x4b) at token.c:68
#8 0x0804a706 in main (argc=0, argv=0xbf952fa4) at main.c:468
(gdb)

I may need some pointers on using gdb, as this is my first time. But
hopefully this backtrace will be useful.

Not really. This is heap corruption; the backtrace corresponds to the
point where the corruption was detected, which is usually long after
the corruption actually occurred.

The usual mechanisms for dealing with heap corruption are:

1. Manually examine the code for errors (alloc/free mismatches,
potential out-of-bounds array writes).

2. Use heap checking tools (libmcheck, Electric Fence, valgrind).

Using option #1, the following is noticable (line 467+):

    else { /* oh well, we tried. */
        G_free_tokens(tokens);
        continue;
    }

The tokens array has already been freed at line 447, so this call is
bogus; remove the G_free_tokens() call, resulting in:

    else { /* oh well, we tried. */
        continue;
    }

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