Details Ticket 2767


Comment | Reply | Take | Open


Serial Number 2767
Subject r.stats bug (due to recent G_store() fix?)
Area grass5.7
Queue grass
Requestors neteler@itc.it
Owner none
Status resolved
Last User Contact Tue Nov 8 08:44:45 2005 (3 yr ago)
Current Priority 30
Final Priority 70
Due No date assigned
Last Action Tue Nov 8 08:44:48 2005 (3 yr ago)
Created Fri Dec 3 18:29:35 2004 (4 yr ago)

Transaction History Ticket 2767


Fri, Dec 3 2004 18:29:35    Request created by mneteler  
Subject: r.stats bug (due to recent G_store() fix?)

Hi,

[ http://grass.itc.it/pipermail/grass5/2004-December/016315.html ]

I tried again in Spearfish location:

r.stats -anC fields,elevation.10m
Segmentation fault

gdb `which r.stats`
GNU gdb Red Hat Linux (6.1post-1.20040607.17rh)
(gdb) r -anC fields,elevation.10m
Starting program:
/hardmnt/thuille0/ssi/software/cvsgrass57/dist.i686-pc-linux-gnu/bin/r.stats
-anC fields,elevation.10m

Program received signal SIGSEGV, Segmentation fault.
0x00a6f666 in G_set_raster_cats_title (title=0xbfff8fd0 "", pcats=0x706b5b98)
at cats.c:1537
1537        pcats->title = G_store (title);
(gdb) bt
#0  0x00a6f666 in G_set_raster_cats_title (title=0xbfff8fd0 "",
pcats=0x706b5b98) at cats.c:1537
#1  0x00a6f57c in G_init_raster_cats (title=0xbfff8fd0 "", pcats=0x706b5b98)
at cats.c:1488
#2  0x00a6dfcb in G__read_cats (element=0xaa9860 "cats", name=0x9331528
"elevation.10m", mapset=0x9331630 "PERMANENT",
    pcats=0x706b5b98, full=1) at cats.c:488
#3  0x00a6dcb5 in G_read_raster_cats (name=0x9331528 "elevation.10m",
mapset=0x9331630 "PERMANENT", pcats=0x706b5b98)
    at cats.c:372
#4  0x00a6dc80 in G_read_cats (name=0x9331528 "elevation.10m",
mapset=0x9331630 "PERMANENT", pcats=0x706b5b98) at cats.c:350
#5  0x0804a402 in main (argc=3, argv=0xbfff9734) at main.c:269

It seems that this bugfix (needed for db.login) needs to be refined:

http://grass.itc.it/pipermail/grass-commit/2004-November/015934.html

But how? Help is welcome (strings in C are not my friends),

 Markus
Mon, Dec 6 2004 18:13:05    Mail sent by guest  
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


Tue, Dec 7 2004 19:29:27    Mail sent by mneteler  
Help ! :-)

I'm really lost with this bug. Some pcats initialization
problem. Before making it worse I cry for help one more
time...

Here the story:
https://intevation.de/rt/webrt?serial_num=2767&display=History

Thanks in advance.

Markus
Tue, Dec 7 2004 22:21:08    Mail sent by pkelly  
I'm not sure this line:
if (title == NULL) title="";
looks right.
Perhaps try changing to
if (title == NULL) *title="";
Makes more logical sense but still might not work.

If it doesn't something like this might:
int 
G_set_raster_cats_title (char *intitle, struct Categories *pcats)
{
    char *title;
    if (intitle == NULL)
      *title="";
    else
      title=intitle;
    pcats->title = G_store (title);
    G_newlines_to_spaces (pcats->title);
    G_strip (pcats->title);
      return 0;
}


Tue, Dec 7 2004 22:27:14    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Tue, 7 Dec 2004 22:27:14 +0100
From Markus Neteler <neteler@itc.it>
To Paul Kelly via RT <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [bug #2767] (grass) r.stats bug (due to recent G_store() fix?)
Message-ID <20041207212714.GA24488@thuille.itc.it>
Mail-Followup-To Paul Kelly via RT <grass-bugs@intevation.de>, grass5@grass.itc.it
References <20041207212108.ED0DB10015F@lists.intevation.de>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
In-Reply-To <20041207212108.ED0DB10015F@lists.intevation.de>
User-Agent Mutt/1.4.1i
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Hello Paul,

On Tue, Dec 07, 2004 at 10:21:08PM +0100, Paul Kelly via RT wrote:
> I'm not sure this line:
> if (title == NULL) title="";
> looks right.
> Perhaps try changing to
> if (title == NULL) *title="";
> Makes more logical sense but still might not work.

I tried, but still segfault.
 
> If it doesn't something like this might:
> int 
> G_set_raster_cats_title (char *intitle, struct Categories *pcats)
> {
>     char *title;
>     if (intitle == NULL)
>       *title="";
>     else
>       title=intitle;
>     pcats->title = G_store (title);
>     G_newlines_to_spaces (pcats->title);
>     G_strip (pcats->title);
>       return 0;
> }

gcc reports 
 cats.c:1539: warning: assignment makes integer from pointer without a cast
here (l 1539 is: *title="";).
Also tried and segfault.

Thanks and sorry for no better news,

 Markus


Wed, Dec 8 2004 01:28:13    Mail sent by tlaronde@polynum.com  
Return-Path <tlaronde@polynum.com>
Delivered-To grass-bugs@lists.intevation.de
From tlaronde@polynum.com
Date Tue, 7 Dec 2004 23:55:58 +0100
To Paul Kelly via RT <grass-bugs@intevation.de>, grass5@grass.itc.it
Subject Re: [GRASS5] Re: [bug #2767] (grass) r.stats bug (due to recent G_store() fix?)
Message-ID <20041207225558.GA3226@polynum.com>
References <20041207212108.ED0DB10015F@lists.intevation.de> <20041207212714.GA24488@thuille.itc.it>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
In-Reply-To <20041207212714.GA24488@thuille.itc.it>
User-Agent Mutt/1.4.2.1i
X-Spam-Status No, hits=-4.7 tagged_above=-999.0 required=3.0 tests=BAYES_00, NO_REAL_NAME
X-Spam-Level
Hello,

I haven't look at the code you are trying to fix (I have some other
stuff ;-), but here are some tips :

On Tue, Dec 07, 2004 at 10:27:14PM +0100, Markus Neteler wrote:
>  
> > If it doesn't something like this might:
> > int 
> > G_set_raster_cats_title (char *intitle, struct Categories *pcats)
> > {
> >     char *title;
> >     if (intitle == NULL)
> >       *title="";
> >     else
> >       title=intitle;
> >     pcats->title = G_store (title);
> >     G_newlines_to_spaces (pcats->title);
> >     G_strip (pcats->title);
> >       return 0;
> > }

title is declared as a char*
title is supposed to hold a value char*, but is current value after the
declaration in the local scope of the function is random (writing to
this destination will cause a mess).

The assignement :

title = "";

is syntactically correct since one affects to a char * a char * ("" is
indeed a pointer to a string reduced to one char '\0'). 
But here title is initialized
with the memory address of the "" string, which is whether put by the
compiler
in read-only memory (since "" is not a variable and doesn't change) or
may be allocated on the stack by some instructions generated by the
compiler (depending on optimization), thus making title points to a
read-only address or an evanescent address (on the stack).
Trying to change the value of the char pointed to by the address of
"", hence the address of title (the char '\0') afterwards is likely to
cause problem. 

The assignement :
*title = "";

is syntactically and logically wrong : one is assigning a pointer ("" is
a pointer to the empty string) to an integer value (a char, since *title
is a char because title is a pointer to char). Furthermore, since title
is not initialized, one is trying to write something in a random address
(that may be initialized to NULL, but this is not guaranteed for
automatic variables at all).

So a correct sequence is :

title = (char *) malloc(expected_size_of_string_plus_trailing_null);
*title = '\0'; /* default to empty if intitle not set */

Cheers,
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.org/  |  http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C


Wed, Dec 8 2004 21:51:08    Mail sent by paul-grass@stjohnspoint.co.uk  
Return-Path <paul-grass@stjohnspoint.co.uk>
Delivered-To grass-bugs@lists.intevation.de
Date Wed, 8 Dec 2004 20:51:04 +0000 (GMT)
From Paul Kelly <paul-grass@stjohnspoint.co.uk>
To tlaronde@polynum.com
Cc grass-bugs@intevation.de, grass5@grass.itc.it
Subject Re: [GRASS5] Re: [bug #2767] (grass) r.stats bug (due to recent G_store() fix?)
In-Reply-To <20041207225558.GA3226@polynum.com>
Message-ID <Pine.LNX.4.60.0412082042190.9914@agrippa.ukshells.co.uk>
References <20041207212108.ED0DB10015F@lists.intevation.de> <20041207212714.GA24488@thuille.itc.it> <20041207225558.GA3226@polynum.com>
MIME-Version 1.0
Content-Type TEXT/PLAIN; charset=US-ASCII; format=flowed
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Hello Thierry

On Tue, 7 Dec 2004 tlaronde@polynum.com wrote:

> Hello,
>
> I haven't look at the code you are trying to fix (I have some other
> stuff ;-), but here are some tips :
>
[...]
Snip explanation of why my suggested fix was completely wrong
[...]
>
> So a correct sequence is :
>
> title = (char *) malloc(expected_size_of_string_plus_trailing_null);
> *title = '\0'; /* default to empty if intitle not set */
>

The first line here is more or less what G_store() does. But the recent 
change added
if ( s == NULL ) return NULL ;
to G_store.

Perhaps (going by what you suggest above) it should look more like:
char *G_store (char *s)
{
   char *buf;

   if ( s == NULL )
     *buf = '\0';
   else
   {
     buf = G_malloc (strlen(s) + 1);
     strcpy (buf, s);
   }
   return buf;
}

so you are returning a pointer to an empty string rather than returning a 
NULL pointer. But I am still not very hopeful.

The funny thing is I am unable to reproduce this bug so cannot test. 
Running 'r.stats -anC fields' in Spearfish with yesterday's 5.7 CVS on IRIX 
produces normal-looking output.

Paul


Thu, Dec 9 2004 10:35:19    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 9 Dec 2004 10:35:16 +0100
From Markus Neteler <neteler@itc.it>
To Paul Kelly via RT <grass-bugs@intevation.de>
Cc grass5 developers list <grass5@grass.itc.it>
Subject Re: [bug #2767] (grass) r.stats bug (due to recent
Message-ID <20041209093516.GD30351@thuille.itc.it>
Mail-Followup-To Paul Kelly via RT <grass-bugs@intevation.de>, grass5 developers list <grass5@grass.itc.it>
References <20041208205108.EE60A102C54@lists.intevation.de>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
In-Reply-To <20041208205108.EE60A102C54@lists.intevation.de>
User-Agent Mutt/1.4.1i
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
On Wed, Dec 08, 2004 at 09:51:08PM +0100, Paul Kelly via RT wrote:
> Hello Thierry
> 
> On Tue, 7 Dec 2004 tlaronde@polynum.com wrote:
> 
> > Hello,
> >
> > I haven't look at the code you are trying to fix (I have some other
> > stuff ;-), but here are some tips :
> >
> [...]
> Snip explanation of why my suggested fix was completely wrong
> [...]
> >
> > So a correct sequence is :
> >
> > title = (char *) malloc(expected_size_of_string_plus_trailing_null);
> > *title = '\0'; /* default to empty if intitle not set */
> >
> 
> The first line here is more or less what G_store() does. But the recent 
> change added
> if ( s == NULL ) return NULL ;
> to G_store.

This change was needed to make db.login happy
(locally discussed with Radim).

> Perhaps (going by what you suggest above) it should look more like:
> char *G_store (char *s)
> {
>    char *buf;
> 
>    if ( s == NULL )
>      *buf = '\0';
>    else
>    {
>      buf = G_malloc (strlen(s) + 1);
>      strcpy (buf, s);
>    }
>    return buf;
> }

... also crashing:

(gdb) r -anC fields,elevation.10m
Starting program: /hardmnt/thuille0/ssi/software/cvsgrass57/dist.i686-pc-linux-gnu/bin/r.stats
-anC fields,elevation.10m

Program received signal SIGSEGV, Segmentation fault.
0x00306657 in G_set_raster_cats_title (title=0xbfffb3c0 "", pcats=0x7a2d4fd0)
at cats.c:1536
1536        pcats->title = G_store (title);
(gdb) bt
#0  0x00306657 in G_set_raster_cats_title (title=0xbfffb3c0 "", pcats=0x7a2d4fd0)
at cats.c:1536
#1  0x0030657c in G_init_raster_cats (title=0xbfffb3c0 "", pcats=0x7a2d4fd0)
at cats.c:1488
#2  0x00304fcb in G__read_cats (element=0x340840 "cats", name=0x94a0520 "elevation.10m",
mapset=0x94a0218 "PERMANENT", pcats=0x7a2d4fd0, full=1) at cats.c:488
#3  0x00304cb5 in G_read_raster_cats (name=0x94a0520 "elevation.10m",
    mapset=0x94a0218 "PERMANENT", pcats=0x7a2d4fd0) at cats.c:372
#4  0x00304c80 in G_read_cats (name=0x94a0520 "elevation.10m", mapset=0x94a0218
"PERMANENT",
    pcats=0x7a2d4fd0) at cats.c:350
#5  0x0804a402 in main (argc=3, argv=0xbfffbb24) at main.c:269

Is it possible that 'pcats' isn't initialized properly?

If I run it in 'ddd' and add a break point to the first line of G_init_raster_cats()
in lib/gis/cats.c:
G_init_raster_cats (char *title, struct Categories *pcats)
{
    G_set_raster_cats_title (title, pcats); 

just before segfaulting, pcats isn't initialized.

So maybe G__read_cats() in G_read_raster_cats() called by G_read_cats() 
already fails? In G__read_cats() the function G_init_raster_cats() is executed,
but pcats is reported as 'disabled' in the ddd debugger at that state.

> so you are returning a pointer to an empty string rather than returning a 
> NULL pointer. But I am still not very hopeful.
> 
> The funny thing is I am unable to reproduce this bug so cannot test. 
> Running 'r.stats -anC fields' in Spearfish with yesterday's 5.7 CVS on IRIX
> produces normal-looking output.

Also here.
The problem appears with

r.stats -anC fields,elevation.10m
Segmentation fault

Markus


Thu, Dec 9 2004 18:09:41    Mail sent by guest  
Hi,

I have reverted the recent G_store() change, however,
it's still crashing:

 (gdb) r -anC fields,elevation.10m
Starting program:
/hardmnt/thuille0/ssi/software/cvsgrass57/dist.i686-pc-linux-gnu/bin/r.stats
-anC fields,elevation.10m

Program received signal SIGSEGV, Segmentation fault.
0x005c7666 in G_set_raster_cats_title (title=0xbfffd7c0 "", pcats=0x2596cff8)
at cats.c:1537
1537        pcats->title = G_store (title);
(gdb) bt
#0  0x005c7666 in G_set_raster_cats_title (title=0xbfffd7c0 "",
pcats=0x2596cff8) at cats.c:1537
#1  0x005c757c in G_init_raster_cats (title=0xbfffd7c0 "", pcats=0x2596cff8)
at cats.c:1488
#2  0x005c5fcb in G__read_cats (element=0x601ac0 "cats", name=0x92c8548
"elevation.10m",
    mapset=0x92c8218 "PERMANENT", pcats=0x2596cff8, full=1) at cats.c:488
#3  0x005c5cb5 in G_read_raster_cats (name=0x92c8548 "elevation.10m",
    mapset=0x92c8218 "PERMANENT", pcats=0x2596cff8) at cats.c:372
#4  0x005c5c80 in G_read_cats (name=0x92c8548 "elevation.10m",
mapset=0x92c8218 "PERMANENT",
    pcats=0x2596cff8) at cats.c:350
#5  0x0804a402 in main (argc=3, argv=0xbfffdf24) at main.c:269


I give up to fix this problem.

Markus
Thu, Dec 9 2004 18:55:37    Mail sent by tlaronde@polynum.com  
Return-Path <tlaronde@polynum.com>
Delivered-To grass-bugs@lists.intevation.de
Date Thu, 9 Dec 2004 18:47:29 +0100
From tlaronde@polynum.com
To Paul Kelly <paul-grass@stjohnspoint.co.uk>
Cc grass-bugs@intevation.de, grass5@grass.itc.it
Subject Re: [GRASS5] Re: [bug #2767] (grass) r.stats bug (due to recent G_store() fix?)
Message-ID <20041209174729.GA103@polynum.com>
References <20041207212108.ED0DB10015F@lists.intevation.de> <20041207212714.GA24488@thuille.itc.it> <20041207225558.GA3226@polynum.com> <Pine.LNX.4.60.0412082042190.9914@agrippa.ukshells.co.uk>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
In-Reply-To <Pine.LNX.4.60.0412082042190.9914@agrippa.ukshells.co.uk>
User-Agent Mutt/1.4.2.1i
X-Spam-Status No, hits=-4.7 tagged_above=-999.0 required=3.0 tests=BAYES_00, NO_REAL_NAME
X-Spam-Level
Hello Paul,

On Wed, Dec 08, 2004 at 08:51:04PM +0000, Paul Kelly wrote:
> Hello Thierry
> 
> 
[snipped]

> The first line here is more or less what G_store() does. But the recent 
> change added
> if ( s == NULL ) return NULL ;
> to G_store.
> 
> Perhaps (going by what you suggest above) it should look more like:
> char *G_store (char *s)
> {
>   char *buf;
> 
>   if ( s == NULL )
>     *buf = '\0';

You have to allocate place for buf to point to even if you only want to
store '\0'. Here buf has some random value. If, on some systems, even
the automatic variables are initialized to zero, or if it happens that
the value of buf is 0, the program will core dump (SEGFAULT). If the
(random since not initialized) value of buf happens to be a valid
address pointing to some free space or not used values, you will be able
to store the '\0' without segfaulting, but for a long run program, it
will probably happen at some moment that another piece of code use
willingly this place (that has not be reserved by *alloc() ) and stores
something else (no more '\0' and you will generate a random output).

so here too :

if (s == NULL) 
	buf = (char *) calloc(1,1); /* alloc 1 byte and zeroes */

but may I suggest that the purpose of G_store() is not to transform a
NULL in a zero length string and that probably, depending on the bug you
are trying to fix, it will be better to keep G_store in its present
state and use for example a test in the caller (if G_store returns NULL,
print an empty string or whatever---I haven't follow the history of the
problem so I don't know the context).

>[..] 
> The funny thing is I am unable to reproduce this bug so cannot test. 
> Running 'r.stats -anC fields' in Spearfish with yesterday's 5.7 CVS on IRIX
> produces normal-looking output.

Precisely due to the random value of buf, which depends on the
environment and the compiler.

Cheers,
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.org/  |  http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C


Thu, Dec 9 2004 19:23:55    Mail sent by tlaronde@polynum.com  
Return-Path <tlaronde@polynum.com>
Delivered-To grass-bugs@lists.intevation.de
From tlaronde@polynum.com
Date Thu, 9 Dec 2004 19:24:03 +0100
To Paul Kelly via RT <grass-bugs@intevation.de>, grass5 developers list <grass5@grass.itc.it>
Subject Re: [GRASS5] Re: [bug #2767] (grass) r.stats bug (due to recent
Message-ID <20041209182403.GB103@polynum.com>
References <20041208205108.EE60A102C54@lists.intevation.de> <20041209093516.GD30351@thuille.itc.it>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
In-Reply-To <20041209093516.GD30351@thuille.itc.it>
User-Agent Mutt/1.4.2.1i
X-Spam-Status No, hits=-4.7 tagged_above=-999.0 required=3.0 tests=BAYES_00, NO_REAL_NAME
X-Spam-Level
On Thu, Dec 09, 2004 at 10:35:16AM +0100, Markus Neteler wrote:
> 
> ... also crashing:
> 
> (gdb) r -anC fields,elevation.10m
> Starting program: /hardmnt/thuille0/ssi/software/cvsgrass57/dist.i686-pc-linux-gnu/bin/r.stats
-anC fields,elevation.10m
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x00306657 in G_set_raster_cats_title (title=0xbfffb3c0 "", pcats=0x7a2d4fd0)
at cats.c:1536
> 1536        pcats->title = G_store (title);

This is the call to G_store (see the previous answer to Paul) since with
the code:

char *buf;

if (s == NULL)
	*buf = '\0';

one is still writing the char '\0' to an unknown address since buf has
a random value (probably 0 in this case, leading to the SEGFAULT; and
no SEGFAULT on a system where buf, not initialized, happens to point
to some valid address---thus trashing some place it doesn't own).

So correct sequence here too: initialize (reserve address) before
writing to it:

if (s == NULL)
	buf = (char *) calloc(1,1); /* 1 byte allocated and destination zeroed */

( same as doing:
buf = (char *) malloc(1);
*buf = '\0';
)

But I still have the intuition that you should test in r.stats, and not
change G_store().

If the program is still segfaulting with such a change, there is another
bug somewhere else...

Cheers,
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
http://www.kergis.org/  |  http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C


Thu, Dec 9 2004 22:40:40    Mail sent by glynn@gclements.plus.com  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <16824.50741.896886.614486@cerise.gclements.plus.com>
Date Thu, 9 Dec 2004 21:40:05 +0000
To guest user via RT <grass-bugs@intevation.de>
Cc grass5@grass.itc.it
Subject Re: [GRASS5] [bug #2767] (grass) r.stats bug (due to recent G_store() fix?)
In-Reply-To <20041206171305.30EE3102BF4@lists.intevation.de>
References <20041206171305.30EE3102BF4@lists.intevation.de>
X-Mailer VM 7.17 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
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>


Thu, Dec 9 2004 22:50:55    Mail sent by glynn@gclements.plus.com  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <16824.51359.13385.617057@cerise.gclements.plus.com>
Date Thu, 9 Dec 2004 21:50:23 +0000
To Paul Kelly via RT <grass-bugs@intevation.de>
Cc neteler@itc.it, grass5@grass.itc.it
Subject Re: [GRASS5] [bug #2767] (grass) r.stats bug (due to recent G_store() fix?)
In-Reply-To <20041207212108.ED0DB10015F@lists.intevation.de>
References <20041207212108.ED0DB10015F@lists.intevation.de>
X-Mailer VM 7.17 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
Paul Kelly via RT wrote:

> I'm not sure this line:
> if (title == NULL) title="";
> looks right.

Looks fine to me. The variable "title" will point to read-only data,
so it can only be read, not written, but that isn't an issue here.

> Perhaps try changing to
> if (title == NULL) *title="";

That's a type error, but it's also guaranteed to segfault (writing to
address zero).

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


Fri, Dec 10 2004 10:18:14    Mail sent by neteler@itc.it  
Return-Path <neteler@itc.it>
Delivered-To grass-bugs@lists.intevation.de
Date Fri, 10 Dec 2004 10:18:10 +0100
From Markus Neteler <neteler@itc.it>
To Glynn Clements via RT <grass-bugs@intevation.de>
Cc grass5 developers list <grass5@grass.itc.it>
Subject Re: [bug #2767] (grass) r.stats bug (due to recent G_store() fix?)
Message-ID <20041210091810.GN17066@thuille.itc.it>
Mail-Followup-To Glynn Clements via RT <grass-bugs@intevation.de>, grass5 developers list <grass5@grass.itc.it>
References <20041209214040.882AE102BFF@lists.intevation.de>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Disposition inline
In-Reply-To <20041209214040.882AE102BFF@lists.intevation.de>
User-Agent Mutt/1.4.1i
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
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


Fri, Dec 10 2004 10:41:39    Mail sent by mneteler  
Message of the day:

r.stats -anC fields,elevation.10m
r.stats:  100%

There was a local leftover of my debugging tests in r.stats.
Of course nobody was able to reproduce it (probably only *after*
the G_store() change revert).

Summary:
- G_store() is as it was before
- r.stats is as it was and works
- probably work to do in db.login

I'll close the bug report now.

Thanks for your patience.

Markus
Fri, Dec 10 2004 10:41:45    Status changed to resolved by mneteler  
Fri, Dec 10 2004 16:57:53    Mail sent by glynn@gclements.plus.com  
Return-Path <glynn@gclements.plus.com>
Delivered-To grass-bugs@lists.intevation.de
From Glynn Clements <glynn@gclements.plus.com>
MIME-Version 1.0
Content-Type text/plain; charset=us-ascii
Content-Transfer-Encoding 7bit
Message-ID <16825.51038.684383.591142@cerise.gclements.plus.com>
Date Fri, 10 Dec 2004 15:57:18 +0000
To Markus Neteler <neteler@itc.it>
Cc Glynn Clements via RT <grass-bugs@intevation.de>, grass5 developers list <grass5@grass.itc.it>
Subject Re: [GRASS5] Re: [bug #2767] (grass) r.stats bug (due to recent G_store() fix?)
In-Reply-To <20041210091810.GN17066@thuille.itc.it>
References <20041209214040.882AE102BFF@lists.intevation.de> <20041210091810.GN17066@thuille.itc.it>
X-Mailer VM 7.17 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-Spam-Status No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level
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>


Fri, Dec 10 2004 16:57:53    Status changed to open by _rt_system  
Sat, Feb 26 2005 17:43:18    Status changed to resolved by mneteler  
Mon, Nov 7 2005 09:48:09    Status changed to open by mneteler  
Mon, Nov 7 2005 09:48:25    Comments added by mneteler  
The bug persists :-(
Tue, Nov 8 2005 08:44:45    Mail sent by mneteler  
Brad has fixed the bug.

Markus
Tue, Nov 8 2005 08:44:48    Status changed to resolved by mneteler  
Comment | Reply | Take | Open

You are currently authenticated as guest.
[Show Configuration] [Login as another user]

Users Guide - Mail Commands - Homepage of RequestTracker 1.0.7 - list any request