|
From: Patrick O. <Pat...@gm...> - 2007-11-24 16:56:12
Attachments:
e_vcard_to_string.txt
|
Hello,
I am trying to find the reason for a segfault that users of
SyncEvolution have reported. All I found so far is a valgrind warning
about a call sequence involving glib, Evolution data server libs and
SyncEvolution (attached), but not the segfault.
I have two problems: first, valgrind seems to ignore the debug
information which was stripped from the shared objects although I have
installed the -dbg packages. Here's the -v output:
==7900== Memcheck, a memory error detector.
==7900== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
==7900== Using LibVEX rev 1732, a library for dynamic binary
translation.
==7900== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
==7900== Using valgrind-3.2.3-Debian, a dynamic binary instrumentation
framework.
==7900== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
==7900==
--7900-- Command line
--7900-- ./syncevolution
--7900-- --quiet
--7900-- --sync
--7900-- refresh-from-client
--7900-- scheduleworld_1
--7900-- vcard30
--7900-- Startup, with flags:
--7900-- --suppressions=/usr/lib/valgrind/debian-libc6-dbg.supp
--7900-- --db-attach=yes
--7900-- -v
--7900-- Contents of /proc/version:
--7900-- Linux version 2.6.22-14-generic (buildd@crested) (gcc version
4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #1 SMP Sun Oct 14
21:45:15 GMT 2007
--7900-- Arch and hwcaps: AMD64, amd64-sse2
--7900-- Page sizes: currently 4096, max supported 4096
--7900-- Valgrind library directory: /usr/lib/valgrind
...
--7900-- Reading syms from /usr/lib/libglib-2.0.so.0.1400.1 (0x6E50000)
--7900-- Reading debug info from /usr/lib/libglib-2.0.so.0.1400.1...
--7900-- ... CRC mismatch (computed 42AC1FC1 wanted 61AC205F)
--7900-- Reading debug info
from /usr/lib/debug/usr/lib/libglib-2.0.so.0.1400.1...
--7900-- ... CRC mismatch (computed 6719C35A wanted 61AC205F)
--7900-- object doesn't have a symbol table
--7900-- Reading syms from /usr/lib/libcurl-gnutls.so.4.0.0 (0x711D000)
...
Why does the CRC not match even for the
original /usr/lib/libglib-2.0.so.0.1400.1?
Second, --db-attach fails. I get the question whether I want to attach,
but typing "Y" just triggers some more output, then the program
continues:
...
==7900== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- Y
starting debugger
--7900-- Reading syms from /lib/libnss_nis-2.6.1.so (0xD65A000)
--7900-- Reading debug info from /lib/libnss_nis-2.6.1.so...
--7900-- ... CRC mismatch (computed DF301D8F wanted 772FED41)
--7900-- object doesn't have a symbol table
--7900-- Reading syms from /lib/libnss_files-2.6.1.so (0xD865000)
--7900-- Reading debug info from /lib/libnss_files-2.6.1.so...
--7900-- ... CRC mismatch (computed E28C1BD2 wanted F59EF7E5)
--7900-- object doesn't have a symbol table
--7900-- REDIR: 0xFFFFFFFFFF600400 (???) redirected to 0x38027B51 (???)
--7900-- REDIR: 0x9346C10 (strnlen) redirected to 0x4C229C0 (strnlen)
==7900==
==7900== Use of uninitialised value of size 8
...
Looking at the source in m_debugger.c I see that one else clause was
missing, so I added it:
if ((res = VG_(waitpid)(pid, &status, 0)) == pid &&
WIFSTOPPED(status) && WSTOPSIG(status) == VKI_SIGSTOP &&
ptrace_setregs(pid, &(VG_(threads)[tid].arch.vex)) == 0 &&
VG_(kill)(pid, VKI_SIGSTOP) == 0 &&
VG_(ptrace)(VKI_PTRACE_DETACH, pid, NULL, 0) == 0)
{
... attach debugger to pid ....
} else {
/* there was no code for the else case */
VG_(message)(Vg_UserMsg, "Cannot attach?!");
}
The message is triggered. Note that I am on a quad core system. A race
condition between the parent executing the code above and the forked
process putting itself to sleep? No, a 1 second sleep in the parent
doesn't help.
After breaking the large term in the if() into small if() statements
with error printing in the failure case I see that ptrace_setregs()
fails: it returns -1. Any suggestions?
My system:
Ubuntu 7.10, 64 bit
Intel Q6700
Linux gollum 2.6.22-14-generic #1 SMP Sun Oct 14 21:45:15 GMT 2007 x86_64 GNU/Linux
valgrind-2.3.2 with Ubuntu 7.10 patches (e.g. to compile with glibc 2.6)
--
Bye, Patrick Ohly
--
Pat...@gm...
http://www.estamos.de/
|
|
Re: [Valgrind-users] valgrind 2.3.2 on Ubuntu 7.10 (64 bit): wrong
debug info CRC, --db-attach fails
From: Tom H. <to...@co...> - 2007-11-24 17:12:51
|
In message <1195923367.6678.97.camel@localhost>
Patrick Ohly <Pat...@gm...> wrote:
> --7900-- Reading syms from /usr/lib/libglib-2.0.so.0.1400.1 (0x6E50000)
> --7900-- Reading debug info from /usr/lib/libglib-2.0.so.0.1400.1...
> --7900-- ... CRC mismatch (computed 42AC1FC1 wanted 61AC205F)
> --7900-- Reading debug info
> from /usr/lib/debug/usr/lib/libglib-2.0.so.0.1400.1...
> --7900-- ... CRC mismatch (computed 6719C35A wanted 61AC205F)
> --7900-- object doesn't have a symbol table
> --7900-- Reading syms from /usr/lib/libcurl-gnutls.so.4.0.0 (0x711D000)
> ...
>
> Why does the CRC not match even for the
> original /usr/lib/libglib-2.0.so.0.1400.1?
Well I wouldn't expect it to match for the base file as that will
have other things in it besides the debug data.
The simple answer is that you don't seem to have the right debug
data installed as you don't have any file with a checksum that
matches the one is the base library.
The way it works is that the base library contains a debuglink
section that gives the leafname of the debug file and a CRC for
it. We then search for a file by that name in a number of places
and if any of them match the CRC then we use it.
On Fedora the leafname is normally the name of the library with
a .debug added on the end, and we look for it in the same directory
as the base library and under /usr/lib/debug (as well as .debug in
the user's home directory I think).
On your system it looks like the leafname doesn't have .debug added
so when we look in the original directory we find the library itself
which obviously don't match. We then look under /usr/lib/debug but
the one there doesn't match either.
Most likely you have update the main package but not the debug
package or something, so they are out of sync.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
Re: [Valgrind-users] valgrind 2.3.2 on Ubuntu 7.10 (64 bit): wrong
debug info CRC, --db-attach fails
From: Julian S. <js...@ac...> - 2007-11-24 21:32:19
|
I don't know what's with the debuginfo reading problem. However: > Second, --db-attach fails. I get the question whether I want to attach, > but typing "Y" just triggers some more output, then the program > continues: This I believe to be a bad interaction between 3.2.3 and kernels 2.6.20 and above, in ptrace. This was fixed recently in the trunk. I suggest you check out and build the svn trunk, as described at http://valgrind.org/downloads/repository.html and let us know if that cures either of the two problems. J |
|
Re: [Valgrind-users] valgrind 2.3.2 on Ubuntu 7.10 (64 bit):
wrong debug info CRC, --db-attach fails
From: Patrick O. <Pat...@gm...> - 2007-11-25 16:13:31
|
On Sat, 2007-11-24 at 22:28 +0100, Julian Seward wrote: > I don't know what's with the debuginfo reading problem. FWIW, gdb also ignores the /usr/lib/debug/usr/lib/libglib-2.0.so.0.1400.1 file. Might indeed be an Ubuntu packaging problem. If I really need the debug information then I'll just recompile libglib. > However: > > > Second, --db-attach fails. I get the question whether I want to attach, > > but typing "Y" just triggers some more output, then the program > > continues: > > This I believe to be a bad interaction between 3.2.3 and kernels > 2.6.20 and above, in ptrace. This was fixed recently in the trunk. Thanks for pointing that out. I compiled trunk and attaching works now, but gdb is confused about the stack: ==17800== Use of uninitialised value of size 8 ==17800== at 0x6EA826E: g_utf8_offset_to_pointer (in /usr/lib/libglib-2.0.so.0.1400.1) ==17800== by 0x4E52C7B: e_vcard_to_string (e-vcard.c:905) ==17800== by 0x41C8CF: EvolutionContactSource::createItem(std::string const&, SyncState) (EvolutionContactSource.cpp:330) ==17800== by 0x40BE2E: EvolutionSyncSource::itemList::iterate() (EvolutionSyncSource.h:345) ==17800== by 0x40C0ED: EvolutionSyncSource::getNextItem() (EvolutionSyncSource.h:237) ==17800== by 0x446CA0: SyncManager::getItem(SyncSource&, SyncItem* (SyncSource::*)()) (SyncManager.cpp:1923) ==17800== by 0x449821: SyncManager::sync() (SyncManager.cpp:1145) ==17800== by 0x43F3E7: SyncClient::sync(SyncManagerConfig&, SyncSource**) (SyncClient.cpp:81) ==17800== by 0x40E0E9: EvolutionSyncClient::sync() (EvolutionSyncClient.cpp:793) ==17800== by 0x408E01: main (syncevolution.cpp:232) ==17800== ==17800== ---- Attach to debugger ? --- [Return/N/n/Y/y/C/c] ---- y ==17800== starting debugger with cmd: /usr/bin/gdb -nw /proc/17808/fd/1014 17808 GNU gdb 6.6-debian Copyright (C) 2006 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 "x86_64-linux-gnu"... Using host libthread_db library "/lib/libthread_db.so.1". Attaching to program: /proc/17808/fd/1014, process 17808 0x0000000006ea826e in ?? () from /lib64/ld-linux-x86-64.so.2 (gdb) where #0 0x0000000006ea826e in ?? () from /lib64/ld-linux-x86-64.so.2 #1 0x000000000f4ee728 in ?? () #2 0x000000000d681060 in ?? () #3 0x0000000004e52c7c in ?? () #4 0x000000000d503f30 in ?? () #5 0x000000000d5dd200 in ?? () #6 0x000000000d5dd2c0 in ?? () #7 0x000000000f3fad98 in ?? () #8 0x00000007fefff710 in ?? () #9 0x000000000d4d2298 in ?? () #10 0x00000007ff0006d0 in ?? () #11 0x0000000000000000 in ?? () I don't know why gdb puts the first address (which is still correct) into ld-linux-x86-64.so.2; according to /proc/17808/maps it is in libglib: 06e50000-06f1c000 r-xp 00000000 fe:00 217559 /usr/lib/libglib-2.0.so.0.1400.1 -- Bye, Patrick Ohly -- Pat...@gm... http://www.estamos.de/ |