Eric:
I may need some pointers on using gdb, as this is my first time. But
hopefully this backtrace will be useful.
Glynn:
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.
Ok. Can gdb be tweaked to produce more meaninful/relevant output in regards
to this error?
Glynn:
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;
}
I'll try this out when I get back to the office on Monday. Thanks.
~ Eric.
On Sat, Oct 21, 2006 at 02:49:31AM -0300, Patton, Eric wrote:
Eric:
>> I may need some pointers on using gdb, as this is my first time. But
>> hopefully this backtrace will be useful.
Glynn:
>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.
Ok. Can gdb be tweaked to produce more meaninful/relevant output in regards
to this error?
If needed, some debugging hints are given here:
http://grass.gdf-hannover.de/wiki/GRASS_Debugging
Markus
Patton, Eric wrote:
>> 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.
Ok. Can gdb be tweaked to produce more meaninful/relevant output in regards
to this error?
No. By the time that corruption is detected, any information which
would help to identify the problem has been lost.
Although, in this case, it appears that it really is a double-free
(the error message says "double free or corruption"; the latter is
more common), and the location to which the backtrace refers
(main.c:468) is the second free.
--
Glynn Clements <glynn@gclements.plus.com>