|
From: Joerg B. <j....@we...> - 2003-04-22 08:54:23
|
Nicholas Nethercote <nj...@ca...> schrieb am 22.04.03 09:59:00:
>
> On Tue, 22 Apr 2003, Joerg Beyer wrote:
>
> > > What I think is the most likely cause: does your program spawn
> > > sub-processes, or is it started from a shell or Perl script? By default,
> > > Valgrind only traces the top process; if the program starts with a
> > > script, Valgrind will trace your shell interpreter or the Perl
> > > interpreter. Use --trace-children=yes to trace all processes.
> >
> > nope, I told apache not to spawn (for the sake of debugging), it the -X
> > option for apache.
>
> Did you try --trace-children=yes? Is your program *not* invoked with a
> script?
yes to both: I call the binary and I tried --trace-children=yes.
>
> If so... your program isn't statically linked? Valgrind doesn't work with
> statically linked apps. Is Valgrind starting up -- ie. you're getting the
ok, that may be the part I was missing. some parts are linked as archive
(e.g. python.a). This is not possible? If so, excuse for missing this part
of the documentation.
> startup message?
yes, I get this:
job@lxdev81b:~/testcops/ns/https-10014.10.2.0.22> valgrind -v --trace-children=yes --leak-check=yes --show-reachable=yes /path/to/bin/httpd -d /path/to/conf -DSSL -DGZIP -DCOPS -X
==15664== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==15664== Copyright (C) 2002, and GNU GPL'd, by Julian Seward.
==15664== Using valgrind-1.9.5, a program instrumentation system for x86-linux.
==15664== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==15664== Startup, with flags:
==15664== --suppressions=/netsite/lib/valgrind/default.supp
==15664== -v
==15664== --trace-children=yes
==15664== --leak-check=yes
==15664== --show-reachable=yes
==15664== Reading suppressions file: /netsite/lib/valgrind/default.supp
==15664== Estimated CPU clock rate is 1265 MHz
==15664==
==15664== Reading syms from /export/home/j/job/testcops/lxdev81b_installed_cops/bin/httpd
==15664== Reading syms from /lib/ld-2.2.5.so
==15664== object doesn't have any debug info
==15664== Reading syms from /netsite/lib/valgrind/vgskin_memcheck.so
==15664== Reading syms from /netsite/lib/valgrind/valgrind.so
==15664== Reading syms from /netsite/opt/xerces/2.2.0/lib/libxerces-c.so.22.0
==15664== Reading syms from /netsite/opt/xalan/1.5/lib/libxalan-c1_5_0.so
==15664== Reading syms from /lib/libcrypt.so.1
==15664== object doesn't have any debug info
==15664== Reading syms from /usr/lib/libgdbm.so.2.0.0
==15664== object doesn't have any debug info
==15664== Reading syms from /netsite/opt/cops-cache/3.1/lib/libcops-cache.so.3.0.1
==15664== Reading syms from /netsite/opt/cinlib/12.1/lib/libcin.so.12.0.1
==15664== Reading syms from /netsite/opt/mico/2.3.7/lib/libmico2.3.7.so
==15664== Reading syms from /netsite/opt/mico/2.3.7/lib/libmicocoss2.3.7.so
==15664== Reading syms from /lib/libdl.so.2
==15664== object doesn't have any debug info
==15664== Reading syms from /lib/libm.so.6
==15664== object doesn't have any debug info
==15664== Reading syms from /netsite/opt/cinlib/12.1/lib/libcincorba.so.12.0.1
==15664== Reading syms from /netsite/lib/valgrind/libpthread.so
==15664== Reading syms from /lib/libutil.so.1
==15664== object doesn't have any debug info
==15664== Reading syms from /lib/libreadline.so.4.3
==15664== Reading syms from /lib/libncurses.so.5.2
==15664== object doesn't have any debug info
==15664== Reading syms from /lib/libnsl.so.1
==15664== object doesn't have any debug info
==15664== Reading syms from /usr/lib/libexpat.so.0.3.0
==15664== object doesn't have any debug info
==15664== Reading syms from /usr/lib/libstdc++.so.5.0.0
==15664== object doesn't have any debug info
==15664== Reading syms from /lib/libgcc_s.so.1
==15664== object doesn't have any debug info
==15664== Reading syms from /lib/libc.so.6
==15664== object doesn't have any debug info
==15664== Reading syms from /netsite/opt/icu/2.2/lib/libicuuc.so.22.0
==15664== Reading syms from /netsite/opt/icu/2.2/lib/libicui18n.so.22.0
==15664== Reading syms from /netsite/opt/icu/2.2/lib/libicudata.so.22.0
==15664== Reading syms from /export/home/j/job/testcops/lxdev81b_installed_cops/libexec/mod_gzip.so
==15664== Conditional jump or move depends on uninitialised value(s)
==15664== at 0x10008691: elf_dynamic_do_rel.4 (in /lib/ld-2.2.5.so)
==15664== by 0x1000896A: _dl_relocate_object (in /lib/ld-2.2.5.so)
==15664== by 0x116450C0: dl_open_worker (in /lib/libc.so.6)
==15664== by 0x10009F95: _dl_catch_error (in /lib/ld-2.2.5.so)
==15664==
==15664== Conditional jump or move depends on uninitialised value(s)
==15664== at 0x10008695: elf_dynamic_do_rel.4 (in /lib/ld-2.2.5.so)
==15664== by 0x1000896A: _dl_relocate_object (in /lib/ld-2.2.5.so)
==15664== by 0x116450C0: dl_open_worker (in /lib/libc.so.6)
==15664== by 0x10009F95: _dl_catch_error (in /lib/ld-2.2.5.so)
==15664== Reading syms from /export/home/j/job/testcops/lxdev81b_installed_cops/libexec/libssl.so
==15664==
==15664== Conditional jump or move depends on uninitialised value(s)
==15664== at 0x100086FA: elf_dynamic_do_rel.4 (in /lib/ld-2.2.5.so)
==15664== by 0x1000896A: _dl_relocate_object (in /lib/ld-2.2.5.so)
==15664== by 0x116450C0: dl_open_worker (in /lib/libc.so.6)
==15664== by 0x10009F95: _dl_catch_error (in /lib/ld-2.2.5.so)
==15664==
==15664== Conditional jump or move depends on uninitialised value(s)
==15664== at 0x1000872F: elf_dynamic_do_rel.4 (in /lib/ld-2.2.5.so)
==15664== by 0x1000896A: _dl_relocate_object (in /lib/ld-2.2.5.so)
==15664== by 0x116450C0: dl_open_worker (in /lib/libc.so.6)
==15664== by 0x10009F95: _dl_catch_error (in /lib/ld-2.2.5.so)
>
> Have you tried Valgrind with other programs, eg. small test ones that have
> deliberate errors in them? What version of Valgrind are you using?
yes, but other, smaller programms work as expected and detect the errors.
valgrinds version is 1.9.5
Joerg
|
|
From: Nicholas N. <nj...@ca...> - 2003-04-22 09:18:32
|
On Tue, 22 Apr 2003, Joerg Beyer wrote: > > If so... your program isn't statically linked? Valgrind doesn't work with > > statically linked apps. Is Valgrind starting up -- ie. you're getting the > > ok, that may be the part I was missing. some parts are linked as archive > (e.g. python.a). This is not possible? If so, excuse for missing this part > of the documentation. No, that should be fine. It's only a problem if the whole program is statically linked, in which case Valgrind won't even start up. > > Have you tried Valgrind with other programs, eg. small test ones that have > > deliberate errors in them? What version of Valgrind are you using? > > yes, but other, smaller programms work as expected and detect the errors. > valgrinds version is 1.9.5 Hmm, very strange. Are you certain that the obvious error you inserted is being executed? Maybe #include memcheck.h and insert a call to VALGRIND_DO_LEAK_CHECK and see if that runs, to make sure that (a) the code is being executed and (b) that Valgrind is seeing the code. I can't think why Valgrind wouldn't be seeing the code, but this behaviour is weird. Apart from that, I'm all out of ideas for the moment, sorry. N |