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

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.

Clueless,
Markus

-------------------------------------------- Managed by Request Tracker

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.

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.

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