10:13 p.m.
I'm trying to run current CVS under valgrind [1] in the hope of tracking
down the elusive "freed lrecord" bug, which has killed my Gnus session 3
times today. However, I'm drowning under a deluge of errors from the
garbage collector. Valgrind says:
Conditional jump or move depends on uninitialised value(s)
at 0x8093855: kkcc_marking (lrecord.h:1583)
by 0x8095D19: garbage_collect_1 (alloc.c:4610)
by 0x80EB006: Feval (eval.c:3522)
by 0x81BC0B4: readevalloop (lread.c:1418)
(It truncates the backtrace to only the last 4 frames.) Attaching GDB
to the XEmacs process reveals that the offending memory_description
array has first element XD_INT, second element XD_UNION, and third
element XD_END, and that kkcc_marking (actually
lispdesc_process_xd_union) is currently working on element 1 of the
array, the XD_UNION element.
The only memory_description I see in the sources that matches this
pattern is rune_description_1 in redisplay.c. Valgrind is complaining
about this one, and this one only, and lots. I got over 30000 of these
before I managed to enter my first Gnus group. I don't understand why
valgrind doesn't like it, since it's a static array. Any clues?
And the number of bad memory accesses inside the X library is just
scary....
Footnotes:
[1] http://developer.kde.org/~sewardj/
--
Jerry James
http://www.ittc.ku.edu/~james/
10:37 p.m.
I wrote:
I'm trying to run current CVS under valgrind [1] in the hope of
tracking
down the elusive "freed lrecord" bug, which has killed my Gnus session 3
times today. However, I'm drowning under a deluge of errors from the
garbage collector. Valgrind says:
I got the freed lrecord crash under valgrind, and valgrind said
... nothing at all. This means that the "freed" lrecord is in allocated
space. The only errors reported were inside the X libraries, and a
bunch of the rune_description_1 errors I reported in the previous
message.
--
Jerry James
http://www.ittc.ku.edu/~james/
11:36 p.m.
Jerry James <james(a)xemacs.org> wrote:
I got the freed lrecord crash under valgrind, and valgrind said
... nothing at all. This means that the "freed" lrecord is in allocated
space. The only errors reported were inside the X libraries, and a
bunch of the rune_description_1 errors I reported in the previous
message.
I haven't been following the saga but, just for verification, you
are *NOT* using motif, and are using XFree86 4.3 or later, right?
[ Motif can have uninitialized variable problems, which are often
"fixed" by running XFree86 4.3 or later (which bzero()'s the memory,
making many uninitialized variable problems in widgets go away). In
general, the use of XFree86 4.3 or later should probably be
recommended, as the bzero()'s can hide a multitude of sins. ]
--
Darryl Okahata
darrylo(a)soco.agilent.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.
2:55 a.m.
Darryl Okahata <darrylo(a)soco.agilent.com> wrote:
I haven't been following the saga but, just for
verification, you
are *NOT* using motif, and are using XFree86 4.3 or later, right?
Right. I am not using motif, and I have RedHat's XFree86-4.3.0-2 RPM
installed. As it turns out, valgrind did me no good at all in this
case. I'm trying to figure out how to make it detect stack errors
(which it is supposed to do out of the box) before I try again.
--
Jerry James
http://www.ittc.ku.edu/~james/
4:05 p.m.
Jerry James <james(a)xemacs.org> wrote:
Right. I am not using motif, and I have RedHat's XFree86-4.3.0-2
RPM
installed. As it turns out, valgrind did me no good at all in this
case. I'm trying to figure out how to make it detect stack errors
(which it is supposed to do out of the box) before I try again.
Unfortunately, I don't think valgrind can detect the kind of errors
that you had in your test program. I think the issue is that your
program was writing into "valid" areas of the stack (that is, an address
above $esp). To do what you want, valgrind would have to know what
parts of the stack belongs to data, and what parts of the stack belongs
to bookkeeping info (return addresses, saved registers, etc.), but
valgrind has no way of knowing that.
[ Now, if your program started writing to negative array indices,
valgrind would have a chance of detecting that, but I don't know if it
actually does. ]
--
Darryl Okahata
darrylo(a)soco.agilent.com
DISCLAIMER: this message is the author's personal opinion and does not
constitute the support, opinion, or policy of Agilent Technologies, or
of the little green men that have been following him all day.
6:49 p.m.
Darryl Okahata <darrylo(a)soco.agilent.com> writes:
[ Now, if your program started writing to negative array indices,
valgrind would have a chance of detecting that, but I don't know if it
actually does. ]
If the corruption is on the stack, how could it know? For instance:
int
somfunc ()
{
int a, b, c;
char array[10];
char *foo, *bar, *baz;
... code that writes into array[-1], array[10], etc. ...
}
How can valgrind detect that the code is faulty if it writes into
otherwise valid regions of the stack? The code will silently corrupt
A, B, C and FOO, BAR, BAZ, and it will (I think) look
indistinguishable from the legitimate code that writes into their
memory.
(All variables allocated on the stack for the purpose of this
discussion.)
9:45 p.m.
On Wed, Oct 15, 2003 at 07:49:39PM +0200, Hrvoje Niksic wrote:
How can valgrind detect that the code is faulty if it writes into
otherwise valid regions of the stack?
By putting guard space between the stack slots. It's probably not
especially easy with arrays, but I'm sure it's doable in most of the
cases.
OG.
10:19 p.m.
Olivier Galibert <galibert(a)pobox.com> writes:
On Wed, Oct 15, 2003 at 07:49:39PM +0200, Hrvoje Niksic wrote:
> How can valgrind detect that the code is faulty if it writes into
> otherwise valid regions of the stack?
By putting guard space between the stack slots.
But how can it distinguish "slots" without analyzing source code
which, as far as I know, valgrind doesn't do? It works for the heap
because valgrind intercepts calls to malloc, but there are no
comparable calls on the stack, at least there shouldn't be in
optimized code. For example:
int a;
int b;
int c[10];
int d;
int e;
How can valgrind know that writing to c[-1] is not a legitimate way to
modify b or d? It doesn't control how a/b/c/d/e are allocated on the
stack, the compiler does.
11:55 p.m.
Hrvoje Niksic <hniksic(a)xemacs.org> wrote:
But how can it distinguish "slots" without analyzing source
code
which, as far as I know, valgrind doesn't do? It works for the heap
because valgrind intercepts calls to malloc, but there are no
comparable calls on the stack, at least there shouldn't be in
optimized code. For example:
int a;
int b;
int c[10];
int d;
int e;
How can valgrind know that writing to c[-1] is not a legitimate way to
modify b or d? It doesn't control how a/b/c/d/e are allocated on the
stack, the compiler does.
You are correct; it does not analyze source code, so it has no hope of
distinguishing valid accesses within a stack frame from invalid accesses
within a stack frame. My hope was that it would catch accesses to a
different stack frame (since the simulated CPU could see that a
subroutine call is being made and save the value of the old bottom of
the stack).
--
Jerry James
http://www.ittc.ku.edu/~james/
12:04 a.m.
Jerry James <james(a)xemacs.org> writes:
You are correct; it does not analyze source code, so it has no hope
of distinguishing valid accesses within a stack frame from invalid
accesses within a stack frame. My hope was that it would catch
accesses to a different stack frame (since the simulated CPU could
see that a subroutine call is being made and save the value of the
old bottom of the stack).
It could indeed. Catching corruption of the parent's stack frame
would be awesome... Legitimate writes to those addresses can be
distinguished because they must come from pointer dereference. C is
not Tcl. :-)
11:51 p.m.
Darryl Okahata <darrylo(a)soco.agilent.com> wrote:
Unfortunately, I don't think valgrind can detect the kind of
errors
that you had in your test program. I think the issue is that your
program was writing into "valid" areas of the stack (that is, an address
above $esp). To do what you want, valgrind would have to know what
parts of the stack belongs to data, and what parts of the stack belongs
to bookkeeping info (return addresses, saved registers, etc.), but
valgrind has no way of knowing that.
[ Now, if your program started writing to negative array indices,
valgrind would have a chance of detecting that, but I don't know if it
actually does. ]
I was misled by:
http://developer.kde.org/~sewardj/docs-20031012/coregrind_intro.html
which says that it detects "reading/writing inappropriate areas on the
stack". Since valgrind simulates the CPU, I imagined that it might mark
the top of a new stack frame and catch accesses beyond that point. It
seemed plausible at the time. At any rate, it appears that valgrind is
not, in fact, doing this.
--
Jerry James, wondering what the definition of "inappropriate" is
http://www.ittc.ku.edu/~james/
11 p.m.
I wrote:
I'm trying to run current CVS under valgrind [1] in the hope of
tracking
down the elusive "freed lrecord" bug, which has killed my Gnus session 3
times today. However, I'm drowning under a deluge of errors from the
garbage collector. Valgrind says:
Conditional jump or move depends on uninitialised value(s)
at 0x8093855: kkcc_marking (lrecord.h:1583)
by 0x8095D19: garbage_collect_1 (alloc.c:4610)
by 0x80EB006: Feval (eval.c:3522)
by 0x81BC0B4: readevalloop (lread.c:1418)
Aw, shoot, the valgrind docs say that you can get this error out of
perfectly good, but optimized, code. Now I get to go back and recompile
without optimization...
This means that valgrind detected ZERO errors, even though XEmacs died
with the "freed lrecord" bug again. That lrecord was still allocated,
as far as libc is concerned. I wonder if valgrind detects bad stack
accesses? The docs claim that it does. Let's try this:
------------------------------------------------------------------------
#include <stdio.h>
static int
bad_stack_access_function ()
{
int i, some_array[4];
for (i = 0; i < 1024; i++)
{
some_array[i] = 5;
}
return i;
}
int
main ()
{
puts ("Here we go!");
bad_stack_access_function ();
puts ("I'm still here!");
return 0;
}
------------------------------------------------------------------------
Nope. I got a great hang, but no valgrind errors. Okay, back to the
drawing board...
--
Jerry James
http://www.ittc.ku.edu/~james/
7710
days inactive
7711
days old
11 comments
4 participants
participants (4)
-
Darryl Okahata -
Hrvoje Niksic -
Jerry James -
Olivier Galibert