Re: [Valgrind-developers] The 'impossible happened'

[Jeremy F. <je...@go...>]

On Tue, 2003-12-23 at 18:22, John Carter wrote:
> The impossible happened. What's more it happened whether I was using
> the --tool=memcheck, lackey or none. So I assume that it is coregrind.
> 
> I tried using gdb on valgrind, but it seems to go where gdb can't
> follow, (It exec's stage2, and somewhere in there Bad Things happen.
> 
> How do you use gdb on stage2?

Well, looking up a source/line reference for 0xB8033A65 would be a good
start.  Just from the look of the fault address (0xABFFEDFC), it seems
that the core is trying to do something with the client's stack.  It
would be interesting to know what the value of ESP is, and what the code
at 0x101048E in your program is doing.

I sent the following to the list the other day about attaching gdb to
Valgrind.  The only extra advice might be to set gdb to ignore SIGSEGV
and set a breakpoint around vg_signals.c:1760.

To debug Valgrind itself, do something like this:

$ VALGRINDLIB=.in_place/  valgrind  '--wait-for-gdb=yes' '--tool=memcheck' memcheck/tests/badrw &
6706
$ ==6706== Memcheck, a memory error detector for x86-linux.
==6706== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==6706== Using valgrind-2.1.0, a program supervision framework for x86-linux.
==6706== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
pid=6706
$ gdb .in_place/stage2 6706
GNU gdb Red Hat Linux (5.3post-0.20021129.18rh)
Copyright 2003 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...
Attaching to program: /home/jeremy/cvs/kde/valgrind/.in_place/stage2, process 6706
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from .in_place//vgskin_memcheck.so...done.
Loaded symbols for .in_place//vgskin_memcheck.so
0xb803dede in vgPlain_do_syscall ()

>>> OK, at this point Valgrind is blocked in a pause() syscall, hence
the vgPlain_do_syscall.  You can set breakpoints and so on:
(gdb) break vgSkin_update_extra
Breakpoint 1 at 0xb015b3f4: file mac_needs.c, line 511.

>>> use this to get to fall out of the pause() and keep going with the
startup
(gdb) jump *$eip
Continuing at 0xb803dede.
==6706== Estimated CPU clock rate is 602 MHz
==6706== For more details, rerun with: -v
==6706==
 
>>> SIGSEGVs are expected and normal - they're used for expanding the
client's stack and shadow memory updates (if your tool uses them) -
these should be invisible to the client (and the tool, since they're not
client events).  Of course, some SIGSEGVs are outright errors in the
client or Valgrind.  Valgrind will try to print messages in the bad
cases.  Using --trace-signals=yes will show more details about these
SEGVs (normal or otherwise).

Program received signal SIGSEGV, Segmentation fault.
0xb8742674 in ?? ()
(gdb) c
Continuing.
 
Breakpoint 1, vgSkin_update_extra (err=0x0) at mac_needs.c:511
511     {
(gdb) bt
#0  vgSkin_update_extra (err=0x0) at mac_needs.c:511
#1  0xb804abc3 in vgSkinInternal_update_extra (err=0x1) at vg_toolint.c:77
#2  0xb80135a2 in vgPlain_maybe_record_error (tid=1, ekind=0, a=0, s=0x0,
    extra=0xbfffe930) at vg_errcontext.c:408
(gdb) n
512        switch (VG_(get_error_kind)(err)) {
(gdb)
529        case OverlapErr:  return sizeof(OverlapExtra);

	J