[GRASS5] Re: [bug #2767] (grass) r.stats bug (due to recent G_store() fix?)

[Markus Neteler]

On Thu, Dec 09, 2004 at 10:40:40PM +0100, Glynn Clements via RT wrote:
> 
> guest user via RT wrote:
> 
> > Trying to fix the new (at least recently discovered) bug
> > in r.stats:
> > 
> > lib/gis/cats.c
> > 
> > int 
> > G_set_raster_cats_title (char *title, struct Categories *pcats)
> > {
> >     if (title == NULL) title="";
> >     pcats->title = G_store (title);     <- it crashes here
> >     G_newlines_to_spaces (pcats->title);
> >     G_strip (pcats->title);
> >       return 0;
> > }
> > 
> > For the crashing map title="" (so above if condition used).
> > Reverting locally store.c (G_store() function) didn't help.
> 
> G_store() calls G_malloc() which calls malloc().
> 
> If a program crashes in either malloc (or calloc, realloc etc) or
> free, it's usually because the heap has become corrupted, typically
> because something wrote beyond the bounds of a dynamically-allocated
> block, overwriting the header of either the current block or the one
> after it.
> 
> IOW, the crash is just a symptom; the bug lies elsewhere.

First question:

Is nobody able to reproduce this bug in GRASS 5.7/Spearfish 5.7:

 r.stats -anC fields,elevation.10m

If no, maybe my gcc version is corrupted?
 gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-42)

? 
 
> Locating this kind of bug can be awkward, as there tend not to be any
> detectable side-effects at the point when the memory is corrupted.
> 
> There are various tools which can be used, including the MALLOC_CHECK_
> environment variable and mcheck/mprobe functions (see the libc Info
> file for details), and third-party memory debugging libraries such as
> Electric Fence.
>

Unfortunately I have not slightest idea of the suggested tools.

Markus