|
From: Julian S. <js...@ac...> - 2009-08-17 22:43:56
|
Hi, I've put a release candidate for the upcoming 3.5.0 release at http://www.valgrind.org/downloads/valgrind-3.5.0-TEST2.tar.bz2 (md5 = ecad07658c427090cd0c5cb3d84bbbba). Please give it a try on platforms which are important to you, and report back any critical problems asap. Also, it would be good to know of successes: if it builds and works on distro X, please say so. I know this tarball builds and runs on a vanilla x86_64 Linux system (opensuse 11.0) and also on whatever the current MacOS is (10.5.8 ?). I haven't tested it on any other systems yet. The NEWS file in the tarball is missing the list of fixed bugs. I'll include those for the final release. J |
|
From: Nicholas N. <n.n...@gm...> - 2009-08-18 00:23:27
|
On Tue, Aug 18, 2009 at 8:52 AM, Julian Seward<js...@ac...> wrote: > > I've put a release candidate for the upcoming 3.5.0 release at > http://www.valgrind.org/downloads/valgrind-3.5.0-TEST2.tar.bz2 > (md5 = ecad07658c427090cd0c5cb3d84bbbba). > > Please give it a try on platforms which are important to you, > and report back any critical problems asap. Also, it would > be good to know of successes: if it builds and works on > distro X, please say so. I ran the regtests on: - Ubuntu 9.04 (default build) - Ubuntu 9.04 (with --enable-only32bit) - Darwin 9.8.0 (which is Mac OS X 10.5.8) Results all look good -- only expected failures. I also briefly checked over the HTML docs, print docs and man pages. They look good too. N |
|
From: John R. <jr...@bi...> - 2009-08-18 04:51:17
|
> I've put a release candidate for the upcoming 3.5.0 release at > http://www.valgrind.org/downloads/valgrind-3.5.0-TEST2.tar.bz2 > (md5 = ecad07658c427090cd0c5cb3d84bbbba). Trying it on Fedora 11 x86_64, I encountered 7 unexpected differences (stderr) and 2 SIGSEGV. kernel-2.6.29.6-217.2.7.fc11.x86_64 #1 SMP Fri Aug 14 20:53:08 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux glibc-2.10.1-4.x86_64 == 494 tests, 7 stderr failures, 0 stdout failures, 0 post failures == memcheck/tests/linux/stack_switch (stderr) memcheck/tests/long_namespace_xml (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/annotate_trace_memory (stderr) drd/tests/tc09_bad_unlock (stderr) tc22_exit_w_lock: valgrind ./tc22_exit_w_lock sh: line 1: 1976 Aborted VALGRIND_LIB=/bigdata/valgrind-3.5.0-TEST2/.in_place VALGRIND_LIB_INNER=/bigdata/valgrind-3.5.0-TEST2/.in_place /bigdata/valgrind-3.5.0-TEST2/./coregrind/valgrind --command-line-only=yes --memcheck:leak-check=no --tool=helgrind ./tc22_exit_w_lock > tc22_exit_w_lock.stdout.out 2> tc22_exit_w_lock.stderr.out Program received signal SIGABRT, Aborted. 0x000000003802d1b9 in do_syscall_WRK () (gdb) bt #0 0x000000003802d1b9 in do_syscall_WRK () #1 0x000000003802d342 in vgPlain_do_syscall (sysno=0x1962, a1=0x6, a2=0x0, a3=0xffffffffffffffff, a4=0x0, a5=0x0, a6=0x0, a7=0x0, a8=0x0) at m_syscall.c:702 #2 0x000000003801df66 in vgPlain_kill (pid=0x6, signo=0x0) at m_libcsignal.c:304 #3 0x000000003802a922 in vgPlain_kill_self (sigNo=0x6) at m_signals.c:1353 #4 0x00000000380233dd in shutdown_actions_NORETURN (tid=<value optimized out>, tids_schedretcode=VgSrc_FatalSig) at m_main.c:2495 #5 0x000000003807beac in run_a_thread_NORETURN (tidW=0x1) at m_syswrap/syswrap-linux.c:146 #6 0x0000000000000000 in ?? () selfrun: (skipping, prereq failed: grep '^#define HAVE_PIE 1' ../../config.h > /dev/null) blockfault: valgrind ./blockfault sh: line 1: 18026 Segmentation fault VALGRIND_LIB=/bigdata/valgrind-3.5.0-TEST2/.in_place VALGRIND_LIB_INNER=/bigdata/valgrind-3.5.0-TEST2/.in_place /bigdata/valgrind-3.5.0-TEST2/./coregrind/valgrind --command-line-only=yes --memcheck:leak-check=no --tool=none ./blockfault > blockfault.stdout.out 2> blockfault.stderr.out Program received signal SIGSEGV, Segmentation fault. 0x0000000402ea7f92 in ?? () (gdb) bt #0 0x0000000402ea7f92 in ?? () #1 0x0000000000014823 in ?? () #2 0x00000000389416a0 in vgPlain_threads () #3 0x0000000402e6bf30 in ?? () #4 0x0000000000001880 in ?? () #5 0x0000000038941690 in vgPlain_threads () #6 0x00000000004008f6 in ?? () #7 0x00000004037a1000 in ?? () #8 0x0000000403973e08 in ?? () #9 0x0000000000000001 in ?? () #10 0x0000000000000002 in ?? () #11 0x0000000000001870 in ?? () #12 0x0000000000000000 in ?? () (gdb) info proc process 6562 cmdline = '/bigdata/valgrind-3.5.0-TEST2/coregrind/valgrind' cwd = '/bigdata/valgrind-3.5.0-TEST2/none/tests/linux' exe = '/bigdata/valgrind-3.5.0-TEST2/none/none-amd64-linux' (gdb) shell cat /proc/6562/maps 00400000-00401000 r-xp 00000000 08:15 18071554 /bigdata/valgrind-3.5.0-TEST2/none/tests/linux/blockfault 00600000-00601000 rw-p 00000000 08:15 18071554 /bigdata/valgrind-3.5.0-TEST2/none/tests/linux/blockfault 04000000-04001000 rwxp 04000000 00:00 0 04800000-04802000 rw-p 04800000 00:00 0 04802000-04803000 r-xp 00000000 08:15 25570295 /bigdata/valgrind-3.5.0-TEST2/coregrind/vgpreload_core-amd64-linux.so 04803000-04a02000 ---p 00001000 08:15 25570295 /bigdata/valgrind-3.5.0-TEST2/coregrind/vgpreload_core-amd64-linux.so 04a02000-04a03000 rw-p 00000000 08:15 25570295 /bigdata/valgrind-3.5.0-TEST2/coregrind/vgpreload_core-amd64-linux.so 04a1a000-04a1b000 rw-p 04a1a000 00:00 0 38000000-381a5000 r-xp 00000000 08:15 25570380 /bigdata/valgrind-3.5.0-TEST2/none/none-amd64-linux 383a5000-383a6000 rw-p 001a5000 08:15 25570380 /bigdata/valgrind-3.5.0-TEST2/none/none-amd64-linux 383a6000-38bd8000 rw-p 383a6000 00:00 0 [heap] 402001000-402e5a000 rwxp 402001000 00:00 0 402e5a000-402e5c000 ---p 402e5a000 00:00 0 402e5c000-402e6c000 rwxp 402e5c000 00:00 0 402e6c000-402e6e000 ---p 402e6c000 00:00 0 402e6e000-40440f000 rwxp 402e6e000 00:00 0 7fefff000-7ff001000 rwxp 7fefff000 00:00 0 3091200000-309121f000 r-xp 00000000 08:0a 647186 /lib64/ld-2.10.1.so 309141e000-309141f000 r--p 0001e000 08:0a 647186 /lib64/ld-2.10.1.so 309141f000-3091420000 rw-p 0001f000 08:0a 647186 /lib64/ld-2.10.1.so 3091600000-3091764000 r-xp 00000000 08:0a 647196 /lib64/libc-2.10.1.so 3091764000-3091964000 ---p 00164000 08:0a 647196 /lib64/libc-2.10.1.so 3091964000-3091968000 r--p 00164000 08:0a 647196 /lib64/libc-2.10.1.so 3091968000-3091969000 rw-p 00168000 08:0a 647196 /lib64/libc-2.10.1.so 3091969000-309196e000 rw-p 3091969000 00:00 0 7ffff7ffe000-7ffff7fff000 r-xp 7ffff7ffe000 00:00 0 [vdso] 7ffffffea000-7ffffffff000 rw-p 7ffffffea000 00:00 0 [stack] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] (gdb) x/i $pc 0x402ea7f92: mov %r8d,(%rdi) (gdb) x/8x $rdi 0x4a03000: Cannot access memory at address 0x4a03000 (gdb) x/12i $pc-0x18 0x402ea7f7a: jne 0x402ea7fa4 0x402ea7f7c: mov -0x8(%rsi),%rdi 0x402ea7f80: movq $0x4008fa,0xa8(%rbp) 0x402ea7f8b: mov $0xd5,%r8 0x402ea7f92: mov %r8d,(%rdi) 0x402ea7f95: movq $0x0,0x0(%rbp) 0x402ea7f9d: movq $0x400905,0xa8(%rbp) 0x402ea7fa8: mov %rsi,0x20(%rbp) 0x402ea7fac: mov (%rsi),%rdi 0x402ea7faf: mov %rdi,0x28(%rbp) 0x402ea7fb3: lea 0x8(%rsi),%rdi 0x402ea7fb7: mov %rdi,0x20(%rbp) (gdb) info reg rax 0x4008f6 0x4008f6 rbx 0x8f60 0x8f60 rcx 0x38b4a440 0x38b4a440 rdx 0x38941690 0x38941690 rsi 0x7ff000090 0x7ff000090 rdi 0x4a03000 0x4a03000 rbp 0x389416a0 0x389416a0 rsp 0x402e6be20 0x402e6be20 r8 0xd5 0xd5 r9 0x1 0x1 r10 0x4008f6 0x4008f6 r11 0x402ea7f78 0x402ea7f78 r12 0x4008f6 0x4008f6 r13 0x38941690 0x38941690 r14 0x1880 0x1880 r15 0x14824 0x14824 rip 0x402ea7f92 0x402ea7f92 eflags 0x10246 [ PF ZF IF RF ] cs 0x33 0x33 ss 0x2b 0x2b ds 0x0 0x0 es 0x0 0x0 fs 0x0 0x0 gs 0x0 0x0 fctrl 0x27f 0x27f fstat 0x0 0x0 ftag 0xffff 0xffff fiseg 0x0 0x0 fioff 0x0 0x0 foseg 0x0 0x0 fooff 0x0 0x0 fop 0x0 0x0 mxcsr 0x1f80 [ IM DM ZM OM UM PM ] --- stack_switch.stderr.exp 2009-08-17 12:35:53.000000000 -0700 +++ stack_switch.stderr.out 2009-08-17 19:07:36.000000000 -0700 @@ -0,0 +1,3 @@ +Syscall param clone(child_tidptr) contains uninitialised byte(s) + ... + --- long_namespace_xml.stderr.exp 2009-08-17 12:35:58.000000000 -0700 +++ long_namespace_xml.stderr.out 2009-08-17 19:07:38.000000000 -0700 @@ -37,7 +37,7 @@ <frame> <ip>0x........</ip> <obj>...</obj> - <fn>abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwx yzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklm</fn> + <fn>_ZN53044basic_iostreamIwSt11char_traitsIwEE</fn> <dir>...</dir> <file>long_namespace_xml.cpp</file> <line>...</line> @@ -64,7 +64,7 @@ <frame> <ip>0x........</ip> <obj>...</obj> - <fn>abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwx yzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklm</fn> + <fn>_ZN53044basic_iostreamIwSt11char_traitsIwEE</fn> <dir>...</dir> <file>long_namespace_xml.cpp</file> <line>...</line> --- tc06_two_races_xml.stderr.exp 2009-08-17 12:35:30.000000000 -0700 +++ tc06_two_races_xml.stderr.out 2009-08-17 19:11:50.000000000 -0700 @@ -44,7 +44,7 @@ <frame> <ip>0x........</ip> <obj>...</obj> - <fn>do_clone</fn> + <fn>do_clone.clone.0</fn> </frame> <frame> <ip>0x........</ip> @@ -294,6 +294,7 @@ <xauxwhat><text>declared at tc06_two_races.c:9</text> <file>tc06_two_races.c</file> <line>...</line> </xauxwhat> </error> + <status> <state>FINISHED</state> <time>...</time> --- tc23_bogus_condwait.stderr.exp 2009-08-17 12:35:29.000000000 -0700 +++ tc23_bogus_condwait.stderr.out 2009-08-17 19:12:22.000000000 -0700 @@ -2,31 +2,38 @@ Thread #x is the program's root thread Thread #x: pthread_cond_{timed}wait called with invalid mutex - at 0x........: pthread_cond_wait@* (hg_intercepts.c:...) + at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...) + by 0x........: pthread_cond_wait@* (hg_intercepts.c:...) by 0x........: main (tc23_bogus_condwait.c:69) Thread #x: pthread_cond_{timed}wait called with un-held mutex - at 0x........: pthread_cond_wait@* (hg_intercepts.c:...) + at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...) + by 0x........: pthread_cond_wait@* (hg_intercepts.c:...) by 0x........: main (tc23_bogus_condwait.c:72) Thread #x: pthread_cond_{timed}wait: cond is associated with a different mutex - at 0x........: pthread_cond_wait@* (hg_intercepts.c:...) + at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...) + by 0x........: pthread_cond_wait@* (hg_intercepts.c:...) by 0x........: main (tc23_bogus_condwait.c:72) Thread #x: pthread_cond_{timed}wait called with mutex of type pthread_rwlock_t* - at 0x........: pthread_cond_wait@* (hg_intercepts.c:...) + at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...) + by 0x........: pthread_cond_wait@* (hg_intercepts.c:...) by 0x........: main (tc23_bogus_condwait.c:75) Thread #x: pthread_cond_{timed}wait: cond is associated with a different mutex - at 0x........: pthread_cond_wait@* (hg_intercepts.c:...) + at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...) + by 0x........: pthread_cond_wait@* (hg_intercepts.c:...) by 0x........: main (tc23_bogus_condwait.c:75) Thread #x: pthread_cond_{timed}wait called with mutex held by a different thread - at 0x........: pthread_cond_wait@* (hg_intercepts.c:...) + at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...) + by 0x........: pthread_cond_wait@* (hg_intercepts.c:...) by 0x........: main (tc23_bogus_condwait.c:78) Thread #x: pthread_cond_{timed}wait: cond is associated with a different mutex - at 0x........: pthread_cond_wait@* (hg_intercepts.c:...) + at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...) + by 0x........: pthread_cond_wait@* (hg_intercepts.c:...) by 0x........: main (tc23_bogus_condwait.c:78) --- tc20_verifywrap.stderr.exp-glibc25-amd64 2009-08-17 12:35:29.000000000 -0700 +++ tc20_verifywrap.stderr.out 2009-08-17 19:12:12.000000000 -0700 @@ -71,12 +71,14 @@ ---------------- pthread_cond_wait et al ---------------- Thread #x: pthread_cond_{timed}wait called with un-held mutex - at 0x........: pthread_cond_wait@* (hg_intercepts.c:...) + at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...) + by 0x........: pthread_cond_wait@* (hg_intercepts.c:...) by 0x........: main (tc20_verifywrap.c:147) Thread #x's call to pthread_cond_wait failed with error code 1 (EPERM: Operation not permitted) - at 0x........: pthread_cond_wait@* (hg_intercepts.c:...) + at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...) + by 0x........: pthread_cond_wait@* (hg_intercepts.c:...) by 0x........: main (tc20_verifywrap.c:147) @@ -86,12 +88,14 @@ FIXME: can't figure out how to verify wrap of pthread_broadcast_signal Thread #x: pthread_cond_{timed}wait called with un-held mutex - at 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...) + at 0x........: pthread_cond_timedwait_WRK (hg_intercepts.c:...) + by 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...) by 0x........: main (tc20_verifywrap.c:165) Thread #x's call to pthread_cond_timedwait failed with error code 22 (EINVAL: Invalid argument) - at 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...) + at 0x........: pthread_cond_timedwait_WRK (hg_intercepts.c:...) + by 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...) by 0x........: main (tc20_verifywrap.c:165) @@ -142,6 +146,12 @@ by 0x........: sem_wait (hg_intercepts.c:...) by 0x........: main (tc20_verifywrap.c:242) +Thread #x's call to sem_post failed + with error code 22 (EINVAL: Invalid argument) + at 0x........: sem_post_WRK (hg_intercepts.c:...) + by 0x........: sem_post (hg_intercepts.c:...) + by 0x........: main (tc20_verifywrap.c:245) + FIXME: can't figure out how to verify wrap of sem_post @@ -152,4 +162,4 @@ ... -ERROR SUMMARY: 20 errors from 20 contexts (suppressed: 0 from 0) +ERROR SUMMARY: 21 errors from 21 contexts (suppressed: 0 from 0) --- tc20_verifywrap.stderr.exp-glibc27-amd64 2009-08-17 12:35:28.000000000 -0700 +++ tc20_verifywrap.stderr.out 2009-08-17 19:12:12.000000000 -0700 @@ -71,12 +71,14 @@ ---------------- pthread_cond_wait et al ---------------- Thread #x: pthread_cond_{timed}wait called with un-held mutex - at 0x........: pthread_cond_wait@* (hg_intercepts.c:...) + at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...) + by 0x........: pthread_cond_wait@* (hg_intercepts.c:...) by 0x........: main (tc20_verifywrap.c:147) Thread #x's call to pthread_cond_wait failed with error code 1 (EPERM: Operation not permitted) - at 0x........: pthread_cond_wait@* (hg_intercepts.c:...) + at 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...) + by 0x........: pthread_cond_wait@* (hg_intercepts.c:...) by 0x........: main (tc20_verifywrap.c:147) @@ -86,12 +88,14 @@ FIXME: can't figure out how to verify wrap of pthread_broadcast_signal Thread #x: pthread_cond_{timed}wait called with un-held mutex - at 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...) + at 0x........: pthread_cond_timedwait_WRK (hg_intercepts.c:...) + by 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...) by 0x........: main (tc20_verifywrap.c:165) Thread #x's call to pthread_cond_timedwait failed with error code 22 (EINVAL: Invalid argument) - at 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...) + at 0x........: pthread_cond_timedwait_WRK (hg_intercepts.c:...) + by 0x........: pthread_cond_timedwait@* (hg_intercepts.c:...) by 0x........: main (tc20_verifywrap.c:165) --- annotate_trace_memory.stderr.exp 2009-08-17 12:36:51.000000000 -0700 +++ annotate_trace_memory.stderr.out 2009-08-17 19:12:48.000000000 -0700 @@ -14,7 +14,7 @@ load 0x........ size 4 (thread x / vc ...) at 0x........: test01::Run() (tsan_unittest.cpp:?) - by 0x........: main (tsan_unittest.cpp:?) + by 0x........: Test::Run() (tsan_unittest.cpp:?) GLOB=2 ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) --- tc09_bad_unlock.stderr.exp 2009-08-17 12:36:52.000000000 -0700 +++ tc09_bad_unlock.stderr.out 2009-08-17 19:14:03.000000000 -0700 @@ -26,7 +26,7 @@ Destroying locked mutex: mutex 0x........, recursion count 1, owner 1. at 0x........: nearly_main (tc09_bad_unlock.c:45) - by 0x........: main (tc09_bad_unlock.c:49) + by 0x........: (below main) mutex 0x........ was first observed at: at 0x........: pthread_mutex_init (drd_pthread_intercepts.c:?) by 0x........: nearly_main (tc09_bad_unlock.c:31) @@ -47,13 +47,5 @@ by 0x........: nearly_main (tc09_bad_unlock.c:41) by 0x........: main (tc09_bad_unlock.c:50) -Destroying locked mutex: mutex 0x........, recursion count 1, owner 1. - at 0x........: nearly_main (tc09_bad_unlock.c:45) - by 0x........: main (tc09_bad_unlock.c:50) -mutex 0x........ was first observed at: - at 0x........: pthread_mutex_init (drd_pthread_intercepts.c:?) - by 0x........: nearly_main (tc09_bad_unlock.c:31) - by 0x........: main (tc09_bad_unlock.c:50) - -ERROR SUMMARY: 8 errors from 7 contexts (suppressed: 0 from 0) +ERROR SUMMARY: 8 errors from 6 contexts (suppressed: 0 from 0) -- |
|
From: John R. <jr...@bi...> - 2009-08-18 05:01:43
|
Here is more info on the SIGSEGV in blockfault:
> blockfault: valgrind ./blockfault
> sh: line 1: 18026 Segmentation fault VALGRIND_LIB=/bigdata/valgrind-3.5.0-TEST2/.in_place VALGRIND_LIB_INNER=/bigdata/valgrind-3.5.0-TEST2/.in_place /bigdata/valgrind-3.5.0-TEST2/./coregrind/valgrind --command-line-only=yes --memcheck:leak-check=no --tool=none ./blockfault> blockfault.stdout.out 2>
> blockfault.stderr.out
>
> Program received signal SIGSEGV, Segmentation fault.
> 04800000-04802000 rw-p 04800000 00:00 0
> 04802000-04803000 r-xp 00000000 08:15 25570295 /bigdata/valgrind-3.5.0-TEST2/coregrind/vgpreload_core-amd64-linux.so
> 04803000-04a02000 ---p 00001000 08:15 25570295 /bigdata/valgrind-3.5.0-TEST2/coregrind/vgpreload_core-amd64-linux.so
> 04a02000-04a03000 rw-p 00000000 08:15 25570295 /bigdata/valgrind-3.5.0-TEST2/coregrind/vgpreload_core-amd64-linux.so
> 04a1a000-04a1b000 rw-p 04a1a000 00:00 0
> (gdb) x/i $pc
> 0x402ea7f92: mov %r8d,(%rdi)
> (gdb) x/8x $rdi
> 0x4a03000: Cannot access memory at address 0x4a03000
(gdb) x/8x $rdi-8*4
0x4a02fe0: 0x00000018 0x00000000 0x00000040 0x00000003
0x4a02ff0: 0x00000002 0x00000000 0x00000318 0x00000000
$ readelf --segments /bigdata/valgrind-3.5.0-TEST2/coregrind/vgpreload_core-amd64-linux.so
Elf file type is DYN (Shared object file)
Entry point 0x470
There are 6 program headers, starting at offset 64
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x000000000000064c 0x000000000000064c R E 200000
LOAD 0x0000000000000650 0x0000000000200650 0x0000000000200650
0x00000000000001c0 0x00000000000001d0 RW 200000
DYNAMIC 0x0000000000000680 0x0000000000200680 0x0000000000200680
0x0000000000000150 0x0000000000000150 RW 8
NOTE 0x0000000000000190 0x0000000000000190 0x0000000000000190
0x0000000000000024 0x0000000000000024 R 4
GNU_EH_FRAME 0x00000000000005f8 0x00000000000005f8 0x00000000000005f8
0x0000000000000014 0x0000000000000014 R 4
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000000000 0x0000000000000000 RW 8
Section to Segment mapping:
Segment Sections...
00 .note.gnu.build-id .gnu.hash .dynsym .dynstr .rela.dyn .rela.plt .init .plt .text .fini .eh_frame_hdr .eh_frame
01 .ctors .dtors .jcr .data.rel.ro .dynamic .got .got.plt .bss
02 .dynamic
03 .note.gnu.build-id
04 .eh_frame_hdr
05
--
|
|
From: Bart V. A. <bar...@gm...> - 2009-08-18 06:45:40
|
On Tue, Aug 18, 2009 at 6:51 AM, John Reiser<jr...@bi...> wrote: >> I've put a release candidate for the upcoming 3.5.0 release at >> http://www.valgrind.org/downloads/valgrind-3.5.0-TEST2.tar.bz2 >> (md5 = ecad07658c427090cd0c5cb3d84bbbba). > > Trying it on Fedora 11 x86_64, I encountered 7 unexpected differences (stderr) and 2 SIGSEGV. > > kernel-2.6.29.6-217.2.7.fc11.x86_64 #1 SMP Fri Aug 14 20:53:08 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux > glibc-2.10.1-4.x86_64 > > == 494 tests, 7 stderr failures, 0 stdout failures, 0 post failures == > memcheck/tests/linux/stack_switch (stderr) > memcheck/tests/long_namespace_xml (stderr) > helgrind/tests/tc06_two_races_xml (stderr) > helgrind/tests/tc20_verifywrap (stderr) > helgrind/tests/tc23_bogus_condwait (stderr) > drd/tests/annotate_trace_memory (stderr) > drd/tests/tc09_bad_unlock (stderr) I'll analyze soon why the above two DRD regression tests fail on Fedora 11 x86_64. > tc22_exit_w_lock: valgrind ./tc22_exit_w_lock > sh: line 1: 1976 Aborted VALGRIND_LIB=/bigdata/valgrind-3.5.0-TEST2/.in_place VALGRIND_LIB_INNER=/bigdata/valgrind-3.5.0-TEST2/.in_place /bigdata/valgrind-3.5.0-TEST2/./coregrind/valgrind --command-line-only=yes --memcheck:leak-check=no --tool=helgrind ./tc22_exit_w_lock > > tc22_exit_w_lock.stdout.out 2> tc22_exit_w_lock.stderr.out If you have a look at the source code of helgrind/tests/tc22_exit_w_lock.c you will see that this program exits by calling kill( getpid(), SIGABRT ). Or: the above is the expected behavior. Bart. |
|
From: John R. <jr...@bi...> - 2009-08-18 14:10:01
|
>> tc22_exit_w_lock: valgrind ./tc22_exit_w_lock >> sh: line 1: 1976 Aborted VALGRIND_LIB=/bigdata/valgrind-3.5.0-TEST2/.in_place VALGRIND_LIB_INNER=/bigdata/valgrind-3.5.0-TEST2/.in_place /bigdata/valgrind-3.5.0-TEST2/./coregrind/valgrind --command-line-only=yes --memcheck:leak-check=no --tool=helgrind ./tc22_exit_w_lock> >> tc22_exit_w_lock.stdout.out 2> tc22_exit_w_lock.stderr.out > If you have a look at the source code of > helgrind/tests/tc22_exit_w_lock.c you will see that this program exits > by calling kill( getpid(), SIGABRT ). Or: the above is the expected > behavior. Hi Bart, Yes, you are correct. I misunderstood "Aborted" as "bad"; sorry. Why does the code use kill(, SIGABRT) instead of exit_group()? Perhaps the SIBABRT was necessary for LinuxThreads when kernel threads were much like a group of separate processes, but now that threads are true threads and NativePosixThreadLibrary (NPTL) treats them as such, I believe that exit_group would work and be more "gentle". -- |
|
From: Bart V. A. <bar...@gm...> - 2009-08-18 07:04:25
|
On Tue, Aug 18, 2009 at 6:51 AM, John Reiser<jr...@bi...> wrote: >> I've put a release candidate for the upcoming 3.5.0 release at >> http://www.valgrind.org/downloads/valgrind-3.5.0-TEST2.tar.bz2 >> (md5 = ecad07658c427090cd0c5cb3d84bbbba). > > Trying it on Fedora 11 x86_64, I encountered 7 unexpected differences (stderr) and 2 SIGSEGV. > > kernel-2.6.29.6-217.2.7.fc11.x86_64 #1 SMP Fri Aug 14 20:53:08 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux > glibc-2.10.1-4.x86_64 > > == 494 tests, 7 stderr failures, 0 stdout failures, 0 post failures == > memcheck/tests/linux/stack_switch (stderr) > memcheck/tests/long_namespace_xml (stderr) > helgrind/tests/tc06_two_races_xml (stderr) > helgrind/tests/tc20_verifywrap (stderr) > helgrind/tests/tc23_bogus_condwait (stderr) > drd/tests/annotate_trace_memory (stderr) > drd/tests/tc09_bad_unlock (stderr) > [...] > > --- annotate_trace_memory.stderr.exp 2009-08-17 12:36:51.000000000 -0700 > +++ annotate_trace_memory.stderr.out 2009-08-17 19:12:48.000000000 -0700 > @@ -14,7 +14,7 @@ > > load 0x........ size 4 (thread x / vc ...) > at 0x........: test01::Run() (tsan_unittest.cpp:?) > - by 0x........: main (tsan_unittest.cpp:?) > + by 0x........: Test::Run() (tsan_unittest.cpp:?) > GLOB=2 > > ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Hello John, The above diff is interesting: while the regression test drd/tests/annotate_trace_memory passes on Tom's x86_64 Fedora 11 system, it fails on your system. Apparently Valgrind generates a different call stack on these two systems. Maybe this is because of a different gcc version ? Which gcc version are you using ? Did you perhaps install the glibc-devel RPM ? Bart. |
|
From: John R. <jr...@bi...> - 2009-08-18 14:01:51
|
>> --- annotate_trace_memory.stderr.exp 2009-08-17 12:36:51.000000000 -0700 >> +++ annotate_trace_memory.stderr.out 2009-08-17 19:12:48.000000000 -0700 >> @@ -14,7 +14,7 @@ >> >> load 0x........ size 4 (thread x / vc ...) >> at 0x........: test01::Run() (tsan_unittest.cpp:?) >> - by 0x........: main (tsan_unittest.cpp:?) >> + by 0x........: Test::Run() (tsan_unittest.cpp:?) >> GLOB=2 >> >> ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) > Hello John, > > The above diff is interesting: while the regression test > drd/tests/annotate_trace_memory passes on Tom's x86_64 Fedora 11 > system, it fails on your system. Apparently Valgrind generates a > different call stack on these two systems. Maybe this is because of a > different gcc version ? Which gcc version are you using ? Did you > perhaps install the glibc-devel RPM ? Hi Bart, I have these glibc-* rpms installed: glibc-2.10.1-4.i686 glibc-2.10.1-4.x86_64 glibc-common-2.10.1-4.x86_64 glibc-debuginfo-2.10.1-4.x86_64 glibc-devel-2.10.1-4.i586 glibc-devel-2.10.1-4.x86_64 glibc-headers-2.10.1-4.x86_64 -- |
|
From: John R. <jr...@bi...> - 2009-08-18 14:16:08
|
>> Which gcc version are you using ? > I have these glibc-* rpms installed: > > glibc-2.10.1-4.i686 > glibc-2.10.1-4.x86_64 > glibc-common-2.10.1-4.x86_64 > glibc-debuginfo-2.10.1-4.x86_64 > glibc-devel-2.10.1-4.i586 > glibc-devel-2.10.1-4.x86_64 > glibc-headers-2.10.1-4.x86_64 > And these compilers: gcc-4.4.0-4.x86_64 gcc-c++-4.4.0-4.x86_64 -- |
|
From: Bart V. A. <bar...@gm...> - 2009-08-19 18:26:02
|
On Tue, Aug 18, 2009 at 4:15 PM, John Reiser <jr...@bi...> wrote: > Which gcc version are you using ? >>> >> > I have these glibc-* rpms installed: >> >> glibc-2.10.1-4.i686 >> glibc-2.10.1-4.x86_64 >> glibc-common-2.10.1-4.x86_64 >> glibc-debuginfo-2.10.1-4.x86_64 >> glibc-devel-2.10.1-4.i586 >> glibc-devel-2.10.1-4.x86_64 >> glibc-headers-2.10.1-4.x86_64 >> >> > And these compilers: > gcc-4.4.0-4.x86_64 > gcc-c++-4.4.0-4.x86_64 Although it's still not entirely clear to me what causes these subtle variations in the call stacks printed by Valgrind, I have filed a bug report that describes this phenomenon (https://bugs.kde.org/show_bug.cgi?id=204441 ). Bart. |
|
From: Bart V. A. <bar...@gm...> - 2009-08-18 20:24:56
|
On Tue, Aug 18, 2009 at 12:52 AM, Julian Seward<js...@ac...> wrote: > > I've put a release candidate for the upcoming 3.5.0 release at > http://www.valgrind.org/downloads/valgrind-3.5.0-TEST2.tar.bz2 > (md5 = ecad07658c427090cd0c5cb3d84bbbba). > > Please give it a try on platforms which are important to you, > and report back any critical problems asap. Also, it would > be good to know of successes: if it builds and works on > distro X, please say so. > > I know this tarball builds and runs on a vanilla x86_64 Linux > system (opensuse 11.0) and also on whatever the current MacOS > is (10.5.8 ?). I haven't tested it on any other systems yet. > > The NEWS file in the tarball is missing the list of fixed > bugs. I'll include those for the final release. Results for ./configure CFLAGS=-pipe && make -s && make -s check && make -s regtest on a few Linux platforms: * openSUSE 11.1 x86_64* == 535 tests, 5 stderr failures, 0 stdout failures, 0 post failures == memcheck/tests/linux/stack_switch (stderr) helgrind/tests/annotate_rwlock (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc23_bogus_condwait (stderr) *openSUSE 10.3 ppc* Memcheck refuses to run any program that calls strlen(). This is a known issue (https://bugs.kde.org/show_bug.cgi?id=182474). I see two possible solutions: either fixing this bug or removing openSUSE ppc from the list of supported platforms. *Fedora 10 i386* == 476 tests, 5 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/origin5-bz2 (stderr) none/tests/cmdline1 (stdout) none/tests/cmdline2 (stdout) none/tests/x86/insn_ssse3 (stdout) none/tests/x86/insn_ssse3 (stderr) none/tests/x86/ssse3_misaligned (stderr) helgrind/tests/tc06_two_races_xml (stderr) exp-ptrcheck/tests/supp (stderr) See also https://bugs.kde.org/show_bug.cgi?id=204317 for the details about none/tests/cmdline[12]. ***CentOS 4.4, i386 * == 475 tests, 35 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/origin1-yes (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/origin6-fp (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/x86-linux/scalar_supp (stderr) none/tests/cmdline1 (stdout) none/tests/cmdline2 (stdout) helgrind/tests/pth_barrier3 (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc08_hbl2 (stdout) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc12_rwl_trivial (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc23_bogus_condwait (stderr) exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/hsg (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) See also https://bugs.kde.org/show_bug.cgi?id=204317 for the details about none/tests/cmdline[12] and https://bugs.kde.org/show_bug.cgi?id=204325 for the details about exp-ptrcheck. The origin tracking tests failed because of subtle differences in the call stacks generated by Valgrind. Bart. |
|
From: Julian S. <js...@ac...> - 2009-08-19 09:21:34
|
Hi Bart, Thanks for the testing. > *openSUSE 10.3 ppc* > > Memcheck refuses to run any program that calls strlen(). This is a known > issue (https://bugs.kde.org/show_bug.cgi?id=182474). Nothing much we can easily do about that. Hopefully the SUSE people will ship a non-stripped ld.so in future. > **CentOS 4.4, i386 > https://bugs.kde.org/show_bug.cgi?id=204325 for the details about > exp-ptrcheck. If you add this to exp-ptrcheck.supp { strlen etc in ld.so exp-ptrcheck:Heap fun:strlen obj:/*lib*/ld-2.*so* obj:/*lib*/ld-2.*so* } does that fix it? J |
|
From: Julian S. <js...@ac...> - 2009-08-19 11:15:20
|
> > **CentOS 4.4, i386 > > https://bugs.kde.org/show_bug.cgi?id=204325 for the details about > > exp-ptrcheck. > > If you add this to exp-ptrcheck.supp > > { > strlen etc in ld.so > exp-ptrcheck:Heap > fun:strlen > obj:/*lib*/ld-2.*so* > obj:/*lib*/ld-2.*so* > } > > does that fix it? Er, cancel that. On looking at the full output you posted, that's obviously not going to "fix" it. J |
|
From: Duncan S. <bal...@fr...> - 2009-08-19 12:45:30
|
>> *openSUSE 10.3 ppc* >> >> Memcheck refuses to run any program that calls strlen(). This is a known >> issue (https://bugs.kde.org/show_bug.cgi?id=182474). > > Nothing much we can easily do about that. Hopefully the SUSE people will > ship a non-stripped ld.so in future. Ubuntu karmic also ships a stripped glibc (causing this valgrind problem). This can be overcome by installing the libc6-dbg package. Since karmic hasn't shipped yet, I guess there still may be time to convince the ubuntu people not to strip their glibc... Ciao, Duncan. |
|
From: Julian S. <js...@ac...> - 2009-08-19 13:21:51
|
On Wednesday 19 August 2009, Duncan Sands wrote: > >> *openSUSE 10.3 ppc* > >> > >> Memcheck refuses to run any program that calls strlen(). This is a known > >> issue (https://bugs.kde.org/show_bug.cgi?id=182474). > > > > Nothing much we can easily do about that. Hopefully the SUSE people will > > ship a non-stripped ld.so in future. > > Ubuntu karmic also ships a stripped glibc (causing this valgrind > problem). This can be overcome by installing the libc6-dbg package. > Since karmic hasn't shipped yet, I guess there still may be time to > convince the ubuntu people not to strip their glibc... It's not the stripping of libc.so that's a problem, only of ld.so. And then it's only that we need to see the entry point for ld.so's private strlen function, and perhaps a couple of others (strcmp?) Valgrind hasn't worked on ppc32-linux on openSUSE for a while, because of this problem. At some point we may end up in the position where Valgrind doesn't work on any distro that ships a stripped ld.so. AFAICT the Fedora people are aware of this, and ship a non-stripped ld.so, so no problem there. But Ubuntu, openSUSE and others are potentially problematic. Do you happen to know the contact email for the ubuntu libc maintainer? It would be best to get them in the loop asap. (Ditto openSUSE). J |
|
From: Duncan S. <bal...@fr...> - 2009-08-19 18:07:02
|
Hi Julian, >> Ubuntu karmic also ships a stripped glibc (causing this valgrind >> problem). This can be overcome by installing the libc6-dbg package. >> Since karmic hasn't shipped yet, I guess there still may be time to >> convince the ubuntu people not to strip their glibc... > > It's not the stripping of libc.so that's a problem, only of ld.so. > And then it's only that we need to see the entry point for ld.so's > private strlen function, and perhaps a couple of others (strcmp?) > > Valgrind hasn't worked on ppc32-linux on openSUSE for a while, because > of this problem. At some point we may end up in the position where > Valgrind doesn't work on any distro that ships a stripped ld.so. > > AFAICT the Fedora people are aware of this, and ship a non-stripped > ld.so, so no problem there. But Ubuntu, openSUSE and others are > potentially problematic. the ld.so symbols are included in the libc6-dbg package, which is consistent with what you say. > Do you happen to know the contact email for the ubuntu libc > maintainer? It would be best to get them in the loop asap. > (Ditto openSUSE). The package says: Maintainer: Ubuntu Core developers <ubu...@li...> Best wishes, Duncan. |
|
From: Duncan S. <bal...@fr...> - 2009-08-21 09:59:27
|
Hi Julian, >> Do you happen to know the contact email for the ubuntu libc >> maintainer? It would be best to get them in the loop asap. >> (Ditto openSUSE). > > The package says: > > Maintainer: Ubuntu Core developers <ubu...@li...> would you like me to contact them? Or would you rather do it yourself? Ciao, Duncan. |
|
From: Julian S. <js...@ac...> - 2009-08-21 13:17:43
|
Hi Duncan, On Friday 21 August 2009, Duncan Sands wrote: > Hi Julian, > > >> Do you happen to know the contact email for the ubuntu libc > >> maintainer? It would be best to get them in the loop asap. > >> (Ditto openSUSE). > > > > The package says: > > > > Maintainer: Ubuntu Core developers > > <ubu...@li...> > > would you like me to contact them? Or would you rather do it yourself? Please do contact them, but keep us in the loop. J |