|
From: Simon J. <ja...@ex...> - 2003-11-30 15:20:32
|
Hello,
I'm using valgrind from Debian, --version says valgrind-20031012.
When trying it on GNU Shishi I have discovered a weird problem. Below
is what happens. If I link with -lgnutls, -lgcrypt, -lgpg-error
-lidn, or -lz instead of -lshishi valgrind do not complain, so the
problem appear to be triggered by -lshishi and not any other library
that is loaded by -lshishi. What could possibly cause this? The
library isn't invoked from main, and I don't use any weird shared
library hooks in -lshishi as far as I'm aware. If I link with 'gcc -o
foo foo.c /usr/local/lib/libshishi.a' valgrind does not complain
tough.
Thanks,
Simon
gcc (GCC) 3.3.2 (Debian)
GNU C Library stable release version 2.3.2, by Roland McGrath et al.
jas@latte:~$ cat>foo.c
#include <stdio.h>
int main()
{
puts("foo");
}
jas@latte:~$ gcc -o foo foo.c -lshishi
jas@latte:~$ valgrind -v ./foo
==3654== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==3654== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==3654== Using valgrind-20031012, a program supervision framework for x86-linux.==3654== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==3654== Command line:
==3654== ./foo
==3654== Startup, with flags:
==3654== --suppressions=/usr/lib/valgrind/default.supp
==3654== -v
==3654== Reading syms from /home/jas/foo
==3654== Reading syms from /lib/ld-2.3.2.so
==3654== object doesn't have a symbol table
==3654== object doesn't have any debug info
==3654== Reading syms from /usr/lib/valgrind/vgskin_memcheck.so
==3654== Reading syms from /usr/lib/valgrind/valgrind.so
==3654== Reading syms from /home/jas/lib/libshishi.so.0.0.9
==3654== Reading syms from /lib/libc-2.3.2.so
==3654== object doesn't have a symbol table
==3654== object doesn't have any debug info
==3654== Reading syms from /usr/lib/libz.so.1.1.4
==3654== object doesn't have a symbol table
==3654== object doesn't have any debug info
==3654== Reading syms from /home/jas/lib/libgnutls.so.8.1.97
==3654== Reading syms from /home/jas/lib/libgcrypt.so.7.3.0
==3654== Reading syms from /home/jas/lib/libgpg-error.so.0.1.1
==3654== Reading syms from /home/jas/lib/libidn.so.11.1.2
==3654== Reading syms from /lib/libresolv-2.3.2.so
==3654== object doesn't have a symbol table
==3654== object doesn't have any debug info
==3654== Reading syms from /lib/libnsl-2.3.2.so
==3654== object doesn't have a symbol table
==3654== object doesn't have any debug info
==3654== Reading suppressions file: /usr/lib/valgrind/default.supp
==3654== Estimated CPU clock rate is 2833 MHz
==3654==
foo
==3654== Invalid free() / delete / delete[]
==3654== at 0x4002CD17: free (vg_replace_malloc.c:231)
==3654== by 0x403AEAAB: (within /lib/libc-2.3.2.so)
==3654== by 0x403AE7F4: __libc_freeres (in /lib/libc-2.3.2.so)
==3654== by 0x4018B3C5: vgPlain___libc_freeres_wrapper (vg_intercept.c:831)
==3654== Address 0x4049B5C0 is not stack'd, malloc'd or free'd
==3654==
==3654== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==3654==
==3654== 1 errors in context 1 of 1:
==3654== Invalid free() / delete / delete[]
==3654== at 0x4002CD17: free (vg_replace_malloc.c:231)
==3654== by 0x403AEAAB: (within /lib/libc-2.3.2.so)
==3654== by 0x403AE7F4: __libc_freeres (in /lib/libc-2.3.2.so)
==3654== by 0x4018B3C5: vgPlain___libc_freeres_wrapper (vg_intercept.c:831)
==3654== Address 0x4049B5C0 is not stack'd, malloc'd or free'd
==3654== IN SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==3654==
==3654== malloc/free: in use at exit: 0 bytes in 0 blocks.
==3654== malloc/free: 0 allocs, 1 frees, 0 bytes allocated.
==3654==
--3654-- TT/TC: 0 tc sectors discarded.
--3654-- 336 chainings, 0 unchainings.
--3654-- translate: new 911 (11780 -> 172397; ratio 146:10)
--3654-- discard 0 (0 -> 0; ratio 0:10).
--3654-- dispatch: 0 jumps (bb entries), of which 1562 (156200%) were unchained.
--3654-- 2/920 major/minor sched events. 912 tt_fast misses.
--3654-- reg-alloc: 87 t-req-spill, 33033+496 orig+spill uis, 4231 total-reg-r.
--3654-- sanity: 3 cheap, 1 expensive checks.
--3654-- ccalls: 3595 C calls, 61% saves+restores avoided (12960 bytes)
--3654-- 4589 args, avg 0.87 setup instrs each (1138 bytes)
--3654-- 0% clear the stack (10785 bytes)
--3654-- 1339 retvals, 34% of reg-reg movs avoided (904 bytes)
jas@latte:~$
|
|
From: Nicholas N. <nj...@ca...> - 2003-12-01 14:08:39
|
On Sun, 30 Nov 2003, Simon Josefsson wrote: > When trying it on GNU Shishi I have discovered a weird problem. Below > is what happens. If I link with -lgnutls, -lgcrypt, -lgpg-error > -lidn, or -lz instead of -lshishi valgrind do not complain, so the > problem appear to be triggered by -lshishi and not any other library > that is loaded by -lshishi. What could possibly cause this? The > library isn't invoked from main, and I don't use any weird shared > library hooks in -lshishi as far as I'm aware. If I link with 'gcc -o > foo foo.c /usr/local/lib/libshishi.a' valgrind does not complain > tough. > ==3654== Invalid free() / delete / delete[] > ==3654== at 0x4002CD17: free (vg_replace_malloc.c:231) > ==3654== by 0x403AEAAB: (within /lib/libc-2.3.2.so) > ==3654== by 0x403AE7F4: __libc_freeres (in /lib/libc-2.3.2.so) > ==3654== by 0x4018B3C5: vgPlain___libc_freeres_wrapper (vg_intercept.c:831) > ==3654== Address 0x4049B5C0 is not stack'd, malloc'd or free'd FAQ #1 explains a bit about __libc_freeres. Your problem is a bit different to that described in FAQ #1, at a guess I'd suspect a glibc bug. I'd suggest either using --run-libc-freeres=no, or writing a suppression for it. N |
|
From: Simon J. <ja...@ex...> - 2003-12-01 16:10:17
|
Nicholas Nethercote <nj...@ca...> writes: > On Sun, 30 Nov 2003, Simon Josefsson wrote: > >> When trying it on GNU Shishi I have discovered a weird problem. Below >> is what happens. If I link with -lgnutls, -lgcrypt, -lgpg-error >> -lidn, or -lz instead of -lshishi valgrind do not complain, so the >> problem appear to be triggered by -lshishi and not any other library >> that is loaded by -lshishi. What could possibly cause this? The >> library isn't invoked from main, and I don't use any weird shared >> library hooks in -lshishi as far as I'm aware. If I link with 'gcc -o >> foo foo.c /usr/local/lib/libshishi.a' valgrind does not complain >> tough. > >> ==3654== Invalid free() / delete / delete[] >> ==3654== at 0x4002CD17: free (vg_replace_malloc.c:231) >> ==3654== by 0x403AEAAB: (within /lib/libc-2.3.2.so) >> ==3654== by 0x403AE7F4: __libc_freeres (in /lib/libc-2.3.2.so) >> ==3654== by 0x4018B3C5: vgPlain___libc_freeres_wrapper (vg_intercept.c:831) >> ==3654== Address 0x4049B5C0 is not stack'd, malloc'd or free'd > > FAQ #1 explains a bit about __libc_freeres. Your problem is a bit > different to that described in FAQ #1, at a guess I'd suspect a glibc bug. > I'd suggest either using --run-libc-freeres=no, or writing a suppression > for it. Yes, I read FAQ #1, but I'm using the latest glibc (which glibc versions are considered too old/buggy in FAQ #1, btw?). But why doesn't the problem occur when I link with other libraries? The glibc is the same. I have been using valgrind extensively on other projects on this machine, so it must be some interaction between this particular library, valgrind and possibly the system. All libraries are built on the same machine, with the same compiler etc. Thanks, Simon |
|
From: Nicholas N. <nj...@ca...> - 2003-12-01 16:23:05
|
On Mon, 1 Dec 2003, Simon Josefsson wrote: > Yes, I read FAQ #1, but I'm using the latest glibc (which glibc > versions are considered too old/buggy in FAQ #1, btw?). But why > doesn't the problem occur when I link with other libraries? The glibc > is the same. I have been using valgrind extensively on other projects > on this machine, so it must be some interaction between this > particular library, valgrind and possibly the system. All libraries > are built on the same machine, with the same compiler etc. I guess that libshishi allocates some memory upon startup (in its .init section, even if it's not used at all), and then something goes wrong later when it tries to deallocate it... which seems to be triggered by __libc_freeres. I don't know anything beyond that. N |
|
From: Simon J. <ja...@ex...> - 2003-12-01 17:05:02
|
Nicholas Nethercote <nj...@ca...> writes: > On Mon, 1 Dec 2003, Simon Josefsson wrote: > >> Yes, I read FAQ #1, but I'm using the latest glibc (which glibc >> versions are considered too old/buggy in FAQ #1, btw?). But why >> doesn't the problem occur when I link with other libraries? The glibc >> is the same. I have been using valgrind extensively on other projects >> on this machine, so it must be some interaction between this >> particular library, valgrind and possibly the system. All libraries >> are built on the same machine, with the same compiler etc. > > I guess that libshishi allocates some memory upon startup (in its .init > section, even if it's not used at all), and then something goes wrong > later when it tries to deallocate it... which seems to be triggered by > __libc_freeres. I don't know anything beyond that. Thanks for the ideas, libshishi.so do define a '_init' symbol, but I didn't write it. So it probably is the default so initializer. Linking with all of the other libraries that libshishi depend on doesn't cause the same problem, so the problem probably isn't a _init from one of the other libraries either. Weird. I'll see if I can remove things from libshishi until the problem disappears. jas@latte:~$ gcc -g -o foo foo.c -lshishi jas@latte:~$ gdb ./foo GNU gdb 5.3-debian Copyright 2002 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-linux"... (gdb) b _init Breakpoint 1 at 0x804836a (gdb) r Starting program: /home/jas/foo Breakpoint 1, 0x0804836a in _init () (gdb) disass Dump of assembler code for function _init: 0x8048364 <_init>: push %ebp 0x8048365 <_init+1>: mov %esp,%ebp 0x8048367 <_init+3>: sub $0x8,%esp 0x804836a <_init+6>: call 0x80483d4 <call_gmon_start> 0x804836f <_init+11>: call 0x8048440 <frame_dummy> 0x8048374 <_init+16>: call 0x8048560 <__do_global_ctors_aux> 0x8048379 <_init+21>: leave 0x804837a <_init+22>: ret End of assembler dump. (gdb) s Single stepping until exit from function _init, which has no line number information. 0x080484bb in __libc_csu_init () (gdb) disass Dump of assembler code for function __libc_csu_init: 0x80484a0 <__libc_csu_init>: push %ebp 0x80484a1 <__libc_csu_init+1>: mov %esp,%ebp 0x80484a3 <__libc_csu_init+3>: push %edi 0x80484a4 <__libc_csu_init+4>: push %esi ... |
|
From: Simon J. <ja...@ex...> - 2003-12-02 03:26:07
|
The problem was a missing -lnsl. Apparently, libgnutls (which libshishi
uses) uses -lnsl, and this forces everything that depend libgnutls to
specify -lnsl as well, otherwise valgrind barfs with the error below. I
guess -lnsl uses _init or does something weird with the dynamic linker.
Thanks for the help, on list and off list.
jas@latte:~$ gcc -o foo foo.c -lshishi
jas@latte:~$ cat foo.c
#include <stdio.h>
int main()
{
puts("foo");
}
jas@latte:~$ gcc -o foo foo.c -lshishi
jas@latte:~$ valgrind --num-callers=10 ./foo
==5091== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==5091== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==5091== Using valgrind-20031012, a program supervision framework for
x86-linux.==5091== Copyright (C) 2000-2003, and GNU GPL'd, by Julian
Seward.
==5091== Estimated CPU clock rate is 2830 MHz
==5091== For more details, rerun with: -v
==5091==
foo
==5091== Invalid free() / delete / delete[]
==5091== at 0x4002CD17: free (vg_replace_malloc.c:231)
==5091== by 0x403ADAAB: (within /lib/libc-2.3.2.so)
==5091== by 0x403AD7F4: __libc_freeres (in /lib/libc-2.3.2.so)
==5091== by 0x4018B3C5: vgPlain___libc_freeres_wrapper
(vg_intercept.c:831)
==5091== by 0x402CD927: exit (in /lib/libc-2.3.2.so)
==5091== by 0x402B7DAD: __libc_start_main (in /lib/libc-2.3.2.so)
==5091== by 0x80483D0: ??? (start.S:102)
==5091== Address 0x40251D10 is not stack'd, malloc'd or free'd
==5091==
==5091== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
==5091== malloc/free: in use at exit: 0 bytes in 0 blocks.
==5091== malloc/free: 0 allocs, 1 frees, 0 bytes allocated.
==5091== For a detailed leak analysis, rerun with: --leak-check=yes
==5091== For counts of detected errors, rerun with: -v
jas@latte:~$ gcc -o foo foo.c -lshishi -lnsl
jas@latte:~$ valgrind --num-callers=10 ./foo
==5099== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==5099== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==5099== Using valgrind-20031012, a program supervision framework for
x86-linux.==5099== Copyright (C) 2000-2003, and GNU GPL'd, by Julian
Seward.
==5099== Estimated CPU clock rate is 2826 MHz
==5099== For more details, rerun with: -v
==5099==
foo
==5099==
==5099== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==5099== malloc/free: in use at exit: 0 bytes in 0 blocks.
==5099== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==5099== For a detailed leak analysis, rerun with: --leak-check=yes
==5099== For counts of detected errors, rerun with: -v
jas@latte:~$
|