Menu
▾
▴
valgrind-users — General discussion list for Valgrind users
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
(58) |
Apr
(261) |
May
(169) |
Jun
(214) |
Jul
(201) |
Aug
(219) |
Sep
(198) |
Oct
(203) |
Nov
(241) |
Dec
(94) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(137) |
Feb
(149) |
Mar
(150) |
Apr
(193) |
May
(95) |
Jun
(173) |
Jul
(137) |
Aug
(236) |
Sep
(157) |
Oct
(150) |
Nov
(136) |
Dec
(90) |
| 2005 |
Jan
(139) |
Feb
(130) |
Mar
(274) |
Apr
(138) |
May
(184) |
Jun
(152) |
Jul
(261) |
Aug
(409) |
Sep
(239) |
Oct
(241) |
Nov
(260) |
Dec
(137) |
| 2006 |
Jan
(191) |
Feb
(142) |
Mar
(169) |
Apr
(75) |
May
(141) |
Jun
(169) |
Jul
(131) |
Aug
(141) |
Sep
(192) |
Oct
(176) |
Nov
(142) |
Dec
(95) |
| 2007 |
Jan
(98) |
Feb
(120) |
Mar
(93) |
Apr
(96) |
May
(95) |
Jun
(65) |
Jul
(62) |
Aug
(56) |
Sep
(53) |
Oct
(95) |
Nov
(106) |
Dec
(87) |
| 2008 |
Jan
(58) |
Feb
(149) |
Mar
(175) |
Apr
(110) |
May
(106) |
Jun
(72) |
Jul
(55) |
Aug
(89) |
Sep
(26) |
Oct
(96) |
Nov
(83) |
Dec
(93) |
| 2009 |
Jan
(97) |
Feb
(106) |
Mar
(74) |
Apr
(64) |
May
(115) |
Jun
(83) |
Jul
(137) |
Aug
(103) |
Sep
(56) |
Oct
(59) |
Nov
(61) |
Dec
(37) |
| 2010 |
Jan
(94) |
Feb
(71) |
Mar
(53) |
Apr
(105) |
May
(79) |
Jun
(111) |
Jul
(110) |
Aug
(81) |
Sep
(50) |
Oct
(82) |
Nov
(49) |
Dec
(21) |
| 2011 |
Jan
(87) |
Feb
(105) |
Mar
(108) |
Apr
(99) |
May
(91) |
Jun
(94) |
Jul
(114) |
Aug
(77) |
Sep
(58) |
Oct
(58) |
Nov
(131) |
Dec
(62) |
| 2012 |
Jan
(76) |
Feb
(93) |
Mar
(68) |
Apr
(95) |
May
(62) |
Jun
(109) |
Jul
(90) |
Aug
(87) |
Sep
(49) |
Oct
(54) |
Nov
(66) |
Dec
(84) |
| 2013 |
Jan
(67) |
Feb
(52) |
Mar
(93) |
Apr
(65) |
May
(33) |
Jun
(34) |
Jul
(52) |
Aug
(42) |
Sep
(52) |
Oct
(48) |
Nov
(66) |
Dec
(14) |
| 2014 |
Jan
(66) |
Feb
(51) |
Mar
(34) |
Apr
(47) |
May
(58) |
Jun
(27) |
Jul
(52) |
Aug
(41) |
Sep
(78) |
Oct
(30) |
Nov
(28) |
Dec
(26) |
| 2015 |
Jan
(41) |
Feb
(42) |
Mar
(20) |
Apr
(73) |
May
(31) |
Jun
(48) |
Jul
(23) |
Aug
(55) |
Sep
(36) |
Oct
(47) |
Nov
(48) |
Dec
(41) |
| 2016 |
Jan
(32) |
Feb
(34) |
Mar
(33) |
Apr
(22) |
May
(14) |
Jun
(31) |
Jul
(29) |
Aug
(41) |
Sep
(17) |
Oct
(27) |
Nov
(38) |
Dec
(28) |
| 2017 |
Jan
(28) |
Feb
(30) |
Mar
(16) |
Apr
(9) |
May
(27) |
Jun
(57) |
Jul
(28) |
Aug
(43) |
Sep
(31) |
Oct
(20) |
Nov
(24) |
Dec
(18) |
| 2018 |
Jan
(34) |
Feb
(50) |
Mar
(18) |
Apr
(26) |
May
(13) |
Jun
(31) |
Jul
(13) |
Aug
(11) |
Sep
(15) |
Oct
(12) |
Nov
(18) |
Dec
(13) |
| 2019 |
Jan
(12) |
Feb
(29) |
Mar
(51) |
Apr
(22) |
May
(13) |
Jun
(20) |
Jul
(13) |
Aug
(12) |
Sep
(21) |
Oct
(6) |
Nov
(9) |
Dec
(5) |
| 2020 |
Jan
(13) |
Feb
(5) |
Mar
(25) |
Apr
(4) |
May
(40) |
Jun
(27) |
Jul
(5) |
Aug
(17) |
Sep
(21) |
Oct
(1) |
Nov
(5) |
Dec
(15) |
| 2021 |
Jan
(28) |
Feb
(6) |
Mar
(11) |
Apr
(5) |
May
(7) |
Jun
(8) |
Jul
(5) |
Aug
(5) |
Sep
(11) |
Oct
(9) |
Nov
(10) |
Dec
(12) |
| 2022 |
Jan
(7) |
Feb
(13) |
Mar
(8) |
Apr
(7) |
May
(12) |
Jun
(27) |
Jul
(14) |
Aug
(27) |
Sep
(27) |
Oct
(17) |
Nov
(17) |
Dec
|
| 2023 |
Jan
(10) |
Feb
(18) |
Mar
(9) |
Apr
(26) |
May
|
Jun
(13) |
Jul
(18) |
Aug
(5) |
Sep
(12) |
Oct
(16) |
Nov
(1) |
Dec
|
| 2024 |
Jan
(4) |
Feb
(3) |
Mar
(6) |
Apr
(17) |
May
(2) |
Jun
(33) |
Jul
(13) |
Aug
(1) |
Sep
(6) |
Oct
(8) |
Nov
(6) |
Dec
(15) |
| 2025 |
Jan
(5) |
Feb
(11) |
Mar
(8) |
Apr
(20) |
May
(1) |
Jun
|
Jul
|
Aug
(6) |
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Alex I. <ale...@in...> - 2003-04-22 16:04:25
|
<!doctype html public "-//w3c//dtd html 4.0 transitional//en"> <html> Hi all, <p>I hope someone can give me a hand here - I am trying to build Valgrind 1.9.5 on RedHat 8 with glibc 2.3.2-4.80 installed. When building, I get the following error: <p>make[3]: Entering directory `/home/agi/tmp/valgrind-1.9.5/corecheck/tests' <br>gcc -Winline -Wall -Wshadow -g -o pth_atfork1 pth_atfork1.o -lpthread <br>pth_atfork1.o: In function `main': <br>/home/agi/tmp/valgrind-1.9.5/corecheck/tests/pth_atfork1.c:68: undefined reference to `pthread_atfork' <br>collect2: ld returned 1 exit status <br>make[3]: *** [pth_atfork1] Error 1 <br>make[3]: Leaving directory `/home/agi/tmp/valgrind-1.9.5/corecheck/tests' <p>Pthread library, bith static and dynamic, do have pthread_atfork symbol defined. And the path to /usr/lib is the firs in LD_LIBRARY_PATH. Any suggestions for me? Thanks beforehand! <p>Alex <pre>-- Alex G. Ivershen Inet Technologies, Inc. Network Products Dept. 1500 N. Greenville Ave. Inet Technologies Inc. Richardson, TX 75081 Phone: +1-469-330-4295 USA "Black Holes are where God divided by zero"</pre> </html> |
|
From: Greg H. <ho...@lu...> - 2003-04-22 14:05:57
|
The raw valgring.spec file in valgrind-1.9.5.tar.bz2 contains an error. In the
files section it neglects to mention the following files.
/usr/bin/valgrind-listener
/usr/bin/vg_regtest
these need to be added, otherwise rpm on RH9 will complain that these files are
in the payload area, but not saved to the rpm.
best rgds,
-Greg
+---------------------------------------------------------------------+
You can release software that's good, software that's inexpensive, or
software that's available on time. You can usually release software
that has 2 of these 3 attributes -- but not all 3.
| Greg Hosler ho...@lu... |
+---------------------------------------------------------------------+
|
|
From: Matthew E. <ma...@gs...> - 2003-04-22 12:12:59
|
> On Mon, 21 Apr 2003, Matthew Emmerton wrote: > > > There has been increasing interest in using Valgrind on the FreeBSD platform > > > > 1) Introduce a mapping layer for syscall #defines. > > > > For example, on Linux we'd have something like this: > > > > vg_syscall.h: > > #define VKI_SC_exit __NR_exit > > #define VKI_SC_getpid __NR_getpid > > > > And on FreeBSD, we'd have something like this: > > > > #define VKI_SC_exit SYS_exit > > #define VKI_SC_getpid SYS_getpid > > Do the *BSD and Linux system calls match as easily as this? Ie. none of > the "equivalent" ones have different arguments or similar? Most of the standard syscalls have matching names and matching data structures. So far, the only syscalls that have really caused me grief are the ones that simply don't exist on FreeBSD, and an #ifdef/#endif pair handles that nicely. Tom Hughes had mentioned including <sys/syscall.h> on Linux which will get SYS_xxx names rather than the __NR_xxx names. I'm curious as to whether this header implements is some sort of SUSv3 or POSIX standard for syscall naming? If so, it would be nice if we could take advantage of it since it would make this particular issue a moot point. > > 2) Introduce a mapping layer for pthread structures > > > > For example, on Linux: > > > > #define VKI_PTHREAD_OWNER __m_owner > > #define VKI_PTHREAD_COUNT __m_count > > #define VKI_PTHREAD_KIND __m_kind > > > > And on FreeBSD: > > > > #define VKI_PTHREAD_OWNER m_owner > > #define VKI_PTHREAD_COUNT m_data.m_count > > #define VKI_PTHREAD_KIND m_type > > Similarly, is there a nice one-to-one mapping between the relevant > structures, such that this simple approach will work? From what I've tried so far, this seems to work just fine -- especially since there are POSIX standards mandating the typing of internal pthread variables. (This is where FreeBSD isn't up to snuff, at least from what I've read.) > Have you tried implementing these layers? It's a nice, simple proposal > you've given, I'd like to know whether it suffices in practice :) Eg. I > imagine many of the syscalls, particularly the common ones, overlap in > *BSD and Linux, but what about the less common ones? Most of what I've done so far in the code is s/Linuxism/BSDism/ and that has been enough to get most of the code to compile and execute properly. There are pieces of code which are definitely OS-specified (most of the assembler stuff, for example) which I have adjusted by hand, and a couple of header (ie, vg_unsafe.h) which I have just rewritten. > Also, you say you have 1.9.5 working with only limited functionality... > what are the other stumbling blocks (you mentioned LDTs)? The biggest is the pthread stuff, which is intertwined with the LDT code, and because of some wierdness in our pthread code, I haven't got it working correctly yet. I will work away at getting more things working and get back to the list with my findings -- this was just a ping to see what the interest level was. Thanks, -- Matt |
|
From: Joerg B. <j....@we...> - 2003-04-22 11:12:14
|
Crispin Flowerday <cr...@th...> schrieb am 22.04.03 13:05:20:
>
> On Tue, 2003-04-22 at 11:55, Nicholas Nethercote wrote:
> > On Tue, 22 Apr 2003, Joerg Beyer wrote:
> >
> > > ok, apache seems to close the filedescriptor - if I use
> > > --logsocket, then I could see the valgrind output.
> >
> > That's a bit odd... Valgrind checks close() syscalls for exactly this
> > case. Did you not get any message like this:
> >
> > Warning: client attempted to close Valgrind's logfile fd (x).
> > Use --logfile-fd=<number> to select an alternative logfile fd.
>
> I have a feeling that Apache will open it's error log file, then use
> dup2() to map stderr to that file. I get valgrind errors in my apache
> error log file when I run it, perhaps the check for valgrind's logfile
> should be in the dup2() system call as well?
yes, hidden under a large pile of other messages. Thanks for
pointing it out.
It now detects my errors that I have inserted with intention.
Please excuse - it was my mistake not to find the valdgrind messages.
Joerg
|
|
From: Crispin F. <cr...@th...> - 2003-04-22 11:06:26
|
On Tue, 2003-04-22 at 11:55, Nicholas Nethercote wrote: > On Tue, 22 Apr 2003, Joerg Beyer wrote: > > > ok, apache seems to close the filedescriptor - if I use > > --logsocket, then I could see the valgrind output. > > That's a bit odd... Valgrind checks close() syscalls for exactly this > case. Did you not get any message like this: > > Warning: client attempted to close Valgrind's logfile fd (x). > Use --logfile-fd=<number> to select an alternative logfile fd. I have a feeling that Apache will open it's error log file, then use dup2() to map stderr to that file. I get valgrind errors in my apache error log file when I run it, perhaps the check for valgrind's logfile should be in the dup2() system call as well? Crispin |
|
From: Nicholas N. <nj...@ca...> - 2003-04-22 10:55:54
|
On Tue, 22 Apr 2003, Joerg Beyer wrote: > ok, apache seems to close the filedescriptor - if I use > --logsocket, then I could see the valgrind output. That's a bit odd... Valgrind checks close() syscalls for exactly this case. Did you not get any message like this: Warning: client attempted to close Valgrind's logfile fd (x). Use --logfile-fd=<number> to select an alternative logfile fd. ? N |
|
From: Joerg B. <j....@we...> - 2003-04-22 09:56:17
|
Nicholas Nethercote <nj...@ca...> schrieb am 22.04.03 11:18:30:
>
> On Tue, 22 Apr 2003, Joerg Beyer wrote:
>
> 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.
ok, apache seems to close the filedescriptor - if I use
--logsocket, then I could see the valgrind output.
Please excuse, that I have not tried that _before_ posting.
Now I have loads of things to check and possibly fix :-)
thanks for your help
Joerg
|
|
From: Joerg B. <j....@we...> - 2003-04-22 09:25:07
|
Nicholas Nethercote <nj...@ca...> schrieb am 22.04.03 11:18:30:
>
> 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
yes, I have picked a place in the source that is executed on inititalization
of the apache module. I even put debug messages before and after that
place (both appeared in the logfile).
> 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.
>
thanks for the guesses. I try to strip the complex code
simpler code and post again if I am able to reduce it so
something simple enough.
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 |
|
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 08:28:48
|
On Mon, 21 Apr 2003, Matthew Emmerton wrote: > There has been increasing interest in using Valgrind on the FreeBSD platform > > 1) Introduce a mapping layer for syscall #defines. > > For example, on Linux we'd have something like this: > > vg_syscall.h: > #define VKI_SC_exit __NR_exit > #define VKI_SC_getpid __NR_getpid > > And on FreeBSD, we'd have something like this: > > #define VKI_SC_exit SYS_exit > #define VKI_SC_getpid SYS_getpid Do the *BSD and Linux system calls match as easily as this? Ie. none of the "equivalent" ones have different arguments or similar? > 2) Introduce a mapping layer for pthread structures > > For example, on Linux: > > #define VKI_PTHREAD_OWNER __m_owner > #define VKI_PTHREAD_COUNT __m_count > #define VKI_PTHREAD_KIND __m_kind > > And on FreeBSD: > > #define VKI_PTHREAD_OWNER m_owner > #define VKI_PTHREAD_COUNT m_data.m_count > #define VKI_PTHREAD_KIND m_type Similarly, is there a nice one-to-one mapping between the relevant structures, such that this simple approach will work? Have you tried implementing these layers? It's a nice, simple proposal you've given, I'd like to know whether it suffices in practice :) Eg. I imagine many of the syscalls, particularly the common ones, overlap in *BSD and Linux, but what about the less common ones? Also, you say you have 1.9.5 working with only limited functionality... what are the other stumbling blocks (you mentioned LDTs)? Thanks. N |
|
From: Tom H. <th...@cy...> - 2003-04-22 08:05:08
|
In message <00f201c30869$f2414d20$120...@gs...>
Matthew Emmerton <ma...@gs...> wrote:
> I propose introducing a vg_syscall.h file that maps the platform's syscall
> #defines to valgrind-specific #defines. This would limit the scope of the
> syscall-related changes required on non-Linux platforms to vg_syscalls.[ch],
> rather than <n> files (<n> currently 7 on FreeBSD) just to patch up the __NR
> syscall symbols.
>
> Although this means another file to keep updated, it provides an easy place
> to document various kernel API changes, with the corresponding
> implementations in vg_syscalls.c.
>
> For example, on Linux, we'd have something like this:
>
> vg_syscall.h:
> #define VKI_SC_exit __NR_exit
> #define VKI_SC_getpid __NR_getpid
>
> And on FreeBSD, we'd have something like this:
>
> #define VKI_SC_exit SYS_exit
> #define VKI_SC_getpid SYS_getpid
Linux does already have defines for the SYS_xxx names and including
sys/syscall.h should get you those defines, which are defined to the
appropriate __NR_xxx name.
Tom
--
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/
|
|
From: Nicholas N. <nj...@ca...> - 2003-04-22 07:59:03
|
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? 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 startup message? Have you tried Valgrind with other programs, eg. small test ones that have deliberate errors in them? What version of Valgrind are you using? N |
|
From: Joerg B. <j....@we...> - 2003-04-22 07:53:06
|
Nicholas Nethercote <nj...@ca...> schrieb am 22.04.03 09:47:45:
>
> 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.
>
> N
>
nope, I told apache not to spawn (for the sake of debugging), it the -X
option for apache.
Joerg
|
|
From: Nicholas N. <nj...@ca...> - 2003-04-22 07:47:48
|
On Tue, 22 Apr 2003, Joerg Beyer wrote: > I have a complicated setup where valgrind is not finding errors. > In my setup I have a apache 1.3 with a c++ module, so it > is mixed C/C++ code. Even at the very first call to initialize > valgrind is not detecting a new[100]/delete (not delete [] !) > pair of calls as error. > > Apache introduces some difficulties for valgrind: > - it is mixed C/C++ code > - all kinds of signal are catched by a signal handler > - all kinds of libraries are linked to the module, like xalan, xerces > - it is a large application with a memory footprint of ~ 20 MB. None of these should pose a problem. 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. N |
|
From: Robert W. <rj...@du...> - 2003-04-22 07:41:07
|
Hi all, Here's a new version of the file descriptor leakage patch that solves a memory error (sigh - this is where being able to valgrind valgrind would be handy) in my original implementation. Feedback welcome. Regards, Robert. -- Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
|
From: Joerg B. <j....@we...> - 2003-04-22 07:24:34
|
Dear Listreaders,
I have a complicated setup where valgrind is not finding errors.
In my setup I have a apache 1.3 with a c++ module, so it
is mixed C/C++ code. Even at the very first call to initialize
valgrind is not detecting a new[100]/delete (not delete [] !)
pair of calls as error.
I inserted the obvious error, because valgrind is not
finding any kind of errors within the module and I cant
believe that :-)
I also introduced other obvius errors (like free'ing not malloc
memory - this is a pure C eror, no C++) without success.
Apache introduces some difficulties for valgrind:
- it is mixed C/C++ code
- all kinds of signal are catched by a signal handler
- all kinds of libraries are linked to the module, like xalan, xerces
- it is a large application with a memory footprint of ~ 20 MB.
I am ware that this is very difficult task for valgrind. Is there anything
I could do to track down, why valgrind is not detecting errors?
Joerg
|
|
From: Matthew E. <ma...@gs...> - 2003-04-22 00:56:37
|
Hi all,
There has been increasing interest in using Valgrind on the FreeBSD platform
and I have been working off and on to make this a reality since the 1.0.0
days. My code base is now a hacked up version of 1.9.5 with very limited
functionality. (No pthreads or LDT support.)
One of the largest stumbling blocks has been the various Linux-isms that are
present in the code, which are expected given the code's history. The two
most major problems which can be addressed by architecture are the use of
hard-coded syscall names and hard-coded pthread internal variable names.
What follows are a couple of proposals that will assist porting valgrind to
non-Linux platforms.
I appreciate any feedback that you may have.
1) Introduce a mapping layer for syscall #defines.
As near as I can tell, all the syscalls referred to outside of vg_syscalls.c
are generic, POSIX-mandated syscalls (exit, execve, getpid, gettimeofday,
etc), and should be present on all UNIX platforms, thus no platform-specific
code outside of vg_syscalls.c.
I propose introducing a vg_syscall.h file that maps the platform's syscall
#defines to valgrind-specific #defines. This would limit the scope of the
syscall-related changes required on non-Linux platforms to vg_syscalls.[ch],
rather than <n> files (<n> currently 7 on FreeBSD) just to patch up the __NR
syscall symbols.
Although this means another file to keep updated, it provides an easy place
to document various kernel API changes, with the corresponding
implementations in vg_syscalls.c.
For example, on Linux, we'd have something like this:
vg_syscall.h:
#define VKI_SC_exit __NR_exit
#define VKI_SC_getpid __NR_getpid
And on FreeBSD, we'd have something like this:
#define VKI_SC_exit SYS_exit
#define VKI_SC_getpid SYS_getpid
2) Introduce a mapping layer for pthread structures
Currently the vg_libpthread.c code assumes the names of pthread_mutex
structure elements. As expected, these are not the same on FreeBSD and are
likely different on the other *BSDs as well.
I propose that we introduce some mapping #defines in vg_kerneliface.h to
handle such differences.
For example, on Linux:
#define VKI_PTHREAD_OWNER __m_owner
#define VKI_PTHREAD_COUNT __m_count
#define VKI_PTHREAD_KIND __m_kind
And on FreeBSD:
#define VKI_PTHREAD_OWNER m_owner
#define VKI_PTHREAD_COUNT m_data.m_count
#define VKI_PTHREAD_KIND m_type
Then we can do things like this instead, which should be more portable:
int __pthread_mutex_init(pthread_mutex_t *mutex,
const pthread_mutexattr_t *mutexattr)
{
mutex->VKI_PTHREAD_COUNT = 0;
mutex->VKI_PTHREAD_OWNER = (_pthread_descr)VG_INVALID_THREADID;
mutex->VKI_PTHREAD_KIND = PTHREAD_MUTEX_ERRORCHECK_NP;
if (mutexattr)
mutex->VKI_PTHREAD_KIND = mutexattr->__mutexkind;
return 0;
}
Thanks,
--
Matt Emmerton
|
|
From: Nicholas N. <nj...@ca...> - 2003-04-21 22:30:02
|
On Wed, 16 Apr 2003, Josef Weidendorfer wrote: > * V should install vg_skin.h (and all its dependents) together with > valgrind.h. This at least would make it possible to adjust compilation of an > external skin to various V skin interface versions. At the moment, I ship my > own vg_skin.h (a copy). Thus I have to ship 2 packages, one for interface 1.2 > (used till Valgrind 1.9.5) and one for interface 2.0 (current CVS), if I want > to support both. So you just want vg_skin.h (and its dependents) to be installed in $prefix/include/valgrind/ -- is that enough? Is this only necessary because of the two interface versions? Hopefully the interface won't change much in the future... > * How to integrate external skin documentation into V documentation? Has > anyone an idea for this? Perhaps an index update script to be run at skin > installation? We could use the valgrind script itself for this: "valgrind > --update-docindex". This should search for all > <prefix>/share/doc/valgrind/*_main.html and generate a start page. Hmm, sounds complicated. Not that I can think of anything better, but it feels like there should be a neater solution. Does external skin documentation even need to be integrated...? N |
|
From: Nicholas N. <nj...@ca...> - 2003-04-21 22:19:31
|
On Wed, 16 Apr 2003, Josef Weidendorfer wrote: > > ------------------------------------ > > ==6863== error: can't open cache simulation output file > > `cachegrind.out.6863' > > ==6863== ... so simulation results will be missing. > > ------------------------------------ > > > > A 0 byte file cachegrind.out.6863 is created. > > Does your program change its cwd (current working directory) while running? Biswapesh, can you confirm if this was the cause of your problem? > I thought that on dump time, cachegrind will check for existence of an empty > cachegrind.out it generates at startup. If it doesn't find it because of a > change of the cwd, you will see the error, as the dump is always created in > the cwd. > > To work around this, I made the "--base=" option to specify a prefix for dump > files. Use an absolute path in the prefix. > > Nick, we should add a implementation of getcwd() to V, and use absolute file > paths. But this still doesn't work with chroot() programs :-( > Another option: --dumpfile-fd=... How's this for a better solution: let's abandon the creation of the cachegrind.out.<pid> file at startup. Originally, Cachegrind aborted if it couldn't open the cachegrind.out.<pid> file, and I put the open-at-startup code in so that if it couldn't open the file, the abort would happen at the start of execution, not at the end after waiting what could be a long time. But then Cachegrind was changed so it didn't abort if the file couldn't be opened, because sometimes with --trace-children=yes it happened often (I can't remember why). So now there's absolutely no point in opening the file at the start and then reopening it at the end. So I'd be happy to remove the opening at the start. But, the cachegrind.out.<pid> file should really be written in the directory the program was invoked from, regardless of any cwd change commands during execution, so the getcwd() implementation still seems like a good idea. Does this sound sensible, Josef? I don't understand the chroot() problem, can you explain it to me, and how it interacts here? N |
|
From: Nicholas N. <nj...@ca...> - 2003-04-21 22:09:16
|
On 20 Apr 2003, Robert Walsh wrote: > The attached patch to the CVS head tracks open file descriptors and > dumps them out at the end of the run. Just curious: have you tried this with many real programs, eg. Mozilla, OpenOffice, KDE or Gnome apps? Did you find in practice that leaked file descriptors is a common problem? The patch looks very clean, BTW, thanks for it. N |
|
From: David E. <da...@2g...> - 2003-04-21 08:54:13
|
On Mon, 2003-04-14 at 11:17, da...@2g... wrote: > Hello, > > Now I have made a small example that has the following properties: > > 1) The server works standalone > > 2) The server works in valgrind 1.0.4 > > 3) The server does not work in valgrind 1.9.5 > > My system is RedHat Linux 8 with the latest updates. Output from `uname -a`: > > Linux zion.2good.net 2.4.18-27.8.0 #1 Fri Mar 14 06:45:49 EST 2003 i686 i686 > i386 GNU/Linux > > Some RPM versions: > > glib-1.2.10-8 > glib-devel-1.2.10-8 > > glibc-2.3.2-4.80.6 > glibc-devel-2.3.2-4.80.6 I would like to add that this problem does not occur with valgrind 1.9.5 on a Debian Stable (Woody) system with the latest updates. Output from `uname -a`: Linux hotstepper.home.2good.net 2.4.16 #4 Thu Nov 29 21:47:57 CET 2001 i686 unknown Some DEB versions: libglib1.2 1.2.10-4 libglib1.2-dev 1.2.10-4 libc6 2.2.5-11.5 libc6-dev 2.2.5-11.5 -- -\- David Eriksson -/- www.2GooD.nu "I personally refuse to use inferior tools because of ideology." - Linus Torvalds |
|
From: David E. <da...@2g...> - 2003-04-21 08:18:07
|
On Mon, 2003-04-21 at 01:54, Julian Seward wrote: > Good. So can I have a copy of the skeleton server to try, + instructions > on how to use it? Did you look at my example code that probably shows the same problem? See this mail I sent a week ago: http://sourceforge.net/mailarchive/message.php?msg_id=4347499 Regards, -\- David Eriksson -/- www.2GooD.nu "I personally refuse to use inferior tools because of ideology." - Linus Torvalds |
|
From: Julian S. <js...@ac...> - 2003-04-20 23:54:48
|
Good. So can I have a copy of the skeleton server to try, + instructions on how to use it? J > Oddly enough, I've been experiencing the same problem. > I'm using Linux Mandrake 9.1, which appears to come with a version of glibc > 2.3.2 (but I think this was happening with older glibc's as well). > > I've written a tiny skeleton server that pre-creates a few threads > (successfully) and then enters a poll loop (from which point the threads > are not getting any cpu time at all). > > It seems that there is some pthreads/poll issue, but this may also be > related that I'm running everything on a laptop and we have already noticed > that there might be some scheduling problems because TSC register being > used is variable-rate on machines with power management active. > > Thanks, > Sefer. > > >That's very strange. V has threading problems with glibcs > 2.3.1, > >though. So I wonder if that's it. Do you have an older linux > >distro you can try it on, something like RH 7.3, or Suse 8.1 ? > >Basically anything with glibc 2.3.1 or before; 2.2.5 would be > >even better. > > > >J > > _________________________________________________________________ > Add photos to your messages with MSN 8. Get 2 months FREE*. > http://join.msn.com/?page=features/featuredemail > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Valgrind-users mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Robert W. <rj...@du...> - 2003-04-20 21:50:38
|
Hi all, The attached patch to the CVS head tracks open file descriptors and dumps them out at the end of the run. If you don't specify any command-line options, you get a summary indicating how many fds are still open. If you specify --fd-list=yes, you get a more verbose list showing the filename (if it exists) for each open file descriptor, along with a backtrace from the point where it was opened. If the fd was inherited from the parent process, no backtrace is produced. The patch knows about file descriptors created by the following system calls: open, dup, dup2, pipe, socket, socketpair and accept. It also knows about file descriptors passed between processes using usix-domain socket cmsg's. Please let me know if I've missed any important calls. The patch also adds VG_(lseek), VG_(readlink) and VG_(getdents) to vg_mylibc, which some other people might find useful too. Regards, Robert. -- Robert Walsh Amalgamated Durables, Inc. - "We don't make the things you buy." Email: rj...@du... |
188 messages has been excluded from this view by a project administrator.
