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
(6) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
1
(6) |
2
(16) |
3
(3) |
4
(11) |
5
(2) |
|
6
(4) |
7
(11) |
8
(4) |
9
(6) |
10
(25) |
11
(10) |
12
(1) |
|
13
(2) |
14
(6) |
15
(16) |
16
(19) |
17
(16) |
18
(5) |
19
|
|
20
(4) |
21
(5) |
22
(21) |
23
(4) |
24
(14) |
25
(3) |
26
(9) |
|
27
(3) |
28
(13) |
29
(6) |
30
(16) |
|
|
|
|
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... |
|
From: Todd R. <ric...@pr...> - 2003-04-20 07:04:29
|
My tests were on both a Gigabyte athlon XP and a Dell 2.53 p4. I was also
about to write a smaller test program, but it looks like you beat me to it -
thx
Todd
----- Original Message -----
From: "Sefer Tov" <se...@ho...>
To: <val...@li...>
Sent: Saturday, April 19, 2003 11:45 PM
Subject: [Valgrind-users] Re: valgrind / pthreads issue
> Hi!
>
> 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: Sefer T. <se...@ho...> - 2003-04-20 06:45:24
|
Hi!
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
|
|
From: Sebastian K. <Seb...@so...> - 2003-04-18 13:13:11
|
From: "Jeremy Fitzhardinge" <je...@go...> > Thinking about it, I quite like Sebastian's idea of a > VALGRIND_STACK_SWITCH(thresh) call. This would mean "when you see a %esp > movement of at least threah bytes, that's a stack switch". This would be a > trigger thing, in that once the motion has been seen, future %esp changes are > seen as being within one stack until another call to VALGRIND_STACK_SWITCH. > > Note that if stacks are closely spaced, thresh would be considerably smaller than > the stack size (since going from a full stack adjacent empty stack just below > would be an %esp movement of less than a stack size - it could be arbitarily > small). Oh, thats the problem. But then, if we're already at placing hints in the source, then maybe another one: VALGRIND_REGISTER_STACK(adr, size) -- this would inform Valgrind that particular memory area is possibly going to become a separate stack at some time in the future. This would also work as invalidator for stack allocated from heap. To make stuff easier nagative value of size would mean that area is below (not above) adr, which could be sometimes more natural approach work stacks growing downwards. Then add VALGRIND_UNREGISTER_STACK(adr). rgds Sebastian Kaliszewski > > J > > > ------------------------------------------------------- > 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: Nicholas N. <nj...@ca...> - 2003-04-18 12:55:11
|
On Fri, 18 Apr 2003, Olly Betts wrote: > > AC_PATH_PROG(GDB, gdb) > > AC_DEFINE(GDB_PATH, @GDB@, "gdb path") > > AC_SUBST(GDB) > > > > doesn't work cause configure don't do subsititution in > > config.h.in when creating config.h, I don't think there is > > any way to put it in config.h.in. > > There is - just use this: > > AC_PATH_PROG(GDB, gdb) > AC_DEFINE_UNQUOTED(GDB_PATH, "$GDB", "gdb with path") Ah, perfect, just what I wanted. I just committed the change. Thanks. N |