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

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

Markus Neteler wrote:

> > 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)

?

It works for me, but a memory-overwrite bug will only have
consequences if the memory which is being overwritten is actually used
for something.

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