|
From: John C. <joh...@ta...> - 2003-12-24 02:22:08
|
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? ==6232== Nulgrind, a binary JIT-compiler for x86-linux. ==6232== Copyright (C) 2002-2003, and GNU GPL'd, by Nicholas Nethercote. ==6232== Using valgrind-2.1.0, a program supervision framework for x86-linux. ==6232== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. ==6232== Valgrind library directory: /usr/local/lib/valgrind ==6232== Command line ==6232== ./test_sicctm ==6232== Startup, with flags: ==6232== -v ==6232== --tool=none ==6232== Reading syms from /lib/ld-2.3.2.so (0xB0000000) ==6232== object doesn't have a symbol table ==6232== object doesn't have any debug info ==6232== Reading syms from /usr/local/lib/valgrind/vgskin_none.so (0xB0018000) ==6232== Reading syms from /lib/tls/libdl-2.3.2.so (0xB0023000) ==6232== object doesn't have a symbol table ==6232== object doesn't have any debug info ==6232== Reading syms from /lib/tls/libc-2.3.2.so (0xB0026000) ==6232== object doesn't have a symbol table ==6232== object doesn't have any debug info ==6232== Reading syms from /usr/local/lib/valgrind/stage2 (0xB8000000) ==6232== Estimated CPU clock rate is 1607 MHz ==6232== REDIRECT soname:libc.so.6(__GI___errno_location) to soname:libpthread.so.0(__errno_location) ==6232== REDIRECT soname:libc.so.6(__errno_location) to soname:libpthread.so.0(__errno_location) ==6232== REDIRECT soname:libc.so.6(__GI___h_errno_location) to soname:libpthread.so.0(__h_errno_location) ==6232== REDIRECT soname:libc.so.6(__h_errno_location) to soname:libpthread.so.0(__h_errno_location) ==6232== REDIRECT soname:libc.so.6(__GI___res_state) to soname:libpthread.so.0(__res_state) ==6232== REDIRECT soname:libc.so.6(__res_state) to soname:libpthread.so.0(__res_state) ==6232== REDIRECT soname:libc.so.6(stpcpy) to *vgpreload_memcheck.so*(stpcpy) ==6232== REDIRECT soname:libc.so.6(strnlen) to *vgpreload_memcheck.so*(strnlen) ==6232== REDIRECT soname:ld-linux.so.2(stpcpy) to *vgpreload_memcheck.so*(stpcpy) ==6232== REDIRECT soname:ld-linux.so.2(strchr) to *vgpreload_memcheck.so*(strchr) ==6232== --6232-- INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --6232-- si_code=1 Fault EIP: 0xB8033A65; Faulting address: 0xABFFEDFC valgrind: the `impossible' happened: Killed by fatal signal Basic block ctr is approximately 750000 ==6232== at 0xB802E37C: vgPlain_core_panic (vg_mylibc.c:1180) ==6232== by 0xB802E37B: panic (vg_mylibc.c:1176) ==6232== by 0xB802E39C: vgPlain_core_panic (vg_mylibc.c:1181) ==6232== by 0xB8034FAB: vg_sync_signalhandler (vg_signals.c:1789) sched status: Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0 ==6232== at 0x101048E: ??? ==6232== by 0x100D879: ??? ==6232== by 0x101623E: ??? ==6232== by 0x1010267: ??? Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: valgrind.kde.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : joh...@ta... New Zealand A Million Monkeys can inflict worse things than just Shakespeare on your system. |
|
From: Jeremy F. <je...@go...> - 2003-12-24 08:39:55
|
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
|