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: Julian S. <js...@ac...> - 2003-04-22 23:30:40
|
Greetings. We've majorly expanded the FAQ to include workarounds for more
or less all failure conditions for which we know a workaround. This includes
a large fraction of the failures people seem to encounter in practice, so
if you've been having problems with V it might be worth taking a look.
The FAQ is below, and we'll included it in all future distributions.
I'll also put it up on the web site.
J
A mini-FAQ for valgrind, version 1.9.6
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Last revised 22 Apr 2003
~~~~~~~~~~~~~~~~~~~~~~~~
-----------------------------------------------------------------
Q1. Programs run OK on valgrind, but at exit produce a bunch
of errors a bit like this
==20755== Invalid read of size 4
==20755== at 0x40281C8A: _nl_unload_locale (loadlocale.c:238)
==20755== by 0x4028179D: free_mem (findlocale.c:257)
==20755== by 0x402E0962: __libc_freeres (set-freeres.c:34)
==20755== by 0x40048DCC: vgPlain___libc_freeres_wrapper
(vg_clientfuncs.c:585)
==20755== Address 0x40CC304C is 8 bytes inside a block of size 380
free'd
==20755== at 0x400484C9: free (vg_clientfuncs.c:180)
==20755== by 0x40281CBA: _nl_unload_locale (loadlocale.c:246)
==20755== by 0x40281218: free_mem (setlocale.c:461)
==20755== by 0x402E0962: __libc_freeres (set-freeres.c:34)
and then die with a segmentation fault.
A1. When the program exits, valgrind runs the procedure
__libc_freeres() in glibc. This is a hook for memory debuggers,
so they can ask glibc to free up any memory it has used. Doing
that is needed to ensure that valgrind doesn't incorrectly
report space leaks in glibc.
Problem is that running __libc_freeres() in older glibc versions
causes this crash.
WORKAROUND FOR 1.1.X and later versions of valgrind: use the
--run-libc-freeres=no flag. You may then get space leak
reports for glibc-allocations (please _don't_ report these
to the glibc people, since they are not real leaks), but at
least the program runs.
-----------------------------------------------------------------
Q2. My program dies complaining that syscall 197 is unimplemented.
A2. 197, which is fstat64, is supported by valgrind. The problem is
that the /usr/include/asm/unistd.h on the machine on which your
valgrind was built, doesn't match your kernel -- or, to be more
specific, glibc is asking your kernel to do a syscall which is
not listed in /usr/include/asm/unistd.h.
The fix is simple. Somewhere near the top of
coregrind/vg_syscalls.c, add the following line:
#define __NR_fstat64 197
Rebuild and try again. The above line should appear before any
uses of the __NR_fstat64 symbol in that file. If you look at the
place where __NR_fstat64 is used in vg_syscalls.c, it will be
obvious why this fix works.
-----------------------------------------------------------------
Q3. My (buggy) program dies like this:
valgrind: vg_malloc2.c:442 (bszW_to_pszW):
Assertion `pszW >= 0' failed.
And/or my (buggy) program runs OK on valgrind, but dies like
this on cachegrind.
A3. If valgrind shows any invalid reads, invalid writes and invalid
frees in your program, the above may happen. Reason is that your
program may trash valgrind's low-level memory manager, which then
dies with the above assertion, or something like this. The cure
is to fix your program so that it doesn't do any illegal memory
accesses. The above failure will hopefully go away after that.
-----------------------------------------------------------------
Q4. I'm running Red Hat Advanced Server. Valgrind always segfaults at
startup.
A4. Known issue with RHAS 2.1, due to funny stack permissions at
startup. However, valgrind-1.9.4 and later automatically handle
this correctly, and should not segfault.
-----------------------------------------------------------------
Q5. I try running "valgrind my_program", but my_program runs normally,
and Valgrind doesn't emit any output at all.
A5. Is my_program statically linked? Valgrind doesn't work with
statically linked binaries. It must rely on at least one shared
object. To detrmine if a my_program is statically linked, run:
ldd my_program
It will show what shared objects my_program relies on, or say:
not a dynamic executable
it my_program is statically linked.
-----------------------------------------------------------------
Q6. I try running "valgrind my_program" and get Valgrind's startup message,
but I don't get any errors and I know my program has errors.
A6. By default, Valgrind only traces the top-level process. So if your
program spawns children, they won't be traced by Valgrind by default.
Also, if your program is started by a shell script, Perl script, or
something similar, Valgrind will trace the shell, or the Perl
interpreter, or equivalent.
To trace child processes, use the --trace-children=yes option.
If you are tracing large trees of processes, it can be less
disruptive to have the output sent over the network. Give
valgrind the flag --logsocket=127.0.0.1:12345 (if you want
logging output sent to port 12345 on localhost). You can
use the valgrind-listener program to listen on that port:
valgrind-listener 12345
Obviously you have to start the listener process first.
See the documentation for more details.
-----------------------------------------------------------------
Q7. My threaded server process runs unbelievably slowly on
valgrind. So slowly, in fact, that at first I thought it
had completely locked up.
A7. We are not completely sure about this, but one possibility
is that laptops with power management fool valgrind's
timekeeping mechanism, which is (somewhat in error) based
on the x86 RDTSC instruction. A "fix" which is claimed to
work is to run some other cpu-intensive process at the same
time, so that the laptop's power-management clock-slowing
does not kick in. We would be interested in hearing more
feedback on this.
-----------------------------------------------------------------
Q8. My program dies (exactly) like this:
REPE then 0xF
valgrind: the `impossible' happened:
Unhandled REPE case
A8. Yeah ... that I believe is a P4 specific instruction. Are you
building your app with -march=pentium4 or something like that?
Others have reported that removing the flag works around this.
In fact this is pretty easy to fix and I do have it on my
to-do-for-1.9.6 list.
I'd be interested to hear if you can get rid of it by changing
your application build flags.
-----------------------------------------------------------------
Q9. My program dies complaining that __libc_current_sigrtmin
is unimplemented.
A9. Try the following. It is an experiment, but it might work.
We would very much appreciate you telling us if it does/
does not work for you.
In vg_libpthread.c, add the 3 functions below.
In vg_libpthread_unimp.c, remove the stubs for the same 3
functions.
Let me know if it helps. Quite a lot of other valgrind users
complain about this, but I have never been able to reproduce it,
so fixing it isn't easy. So it's useful if you can try.
int __libc_current_sigrtmin (void)
{
return -1;
}
int __libc_current_sigrtmax (void)
{
return -1;
}
int __libc_allocate_rtsig (int high)
{
return -1;
}
-----------------------------------------------------------------
Q10. I upgraded to Red Hat 9 and threaded programs now act
strange / deadlock when they didn't before.
A10. Thread support on glibc 2.3.2+ with NPTL is not as
good as on older LinuxThreads-based systems. We have
this under consideration. Avoid Red Hat >= 8.1 for
the time being, if you can.
-----------------------------------------------------------------
Q11. I really need to use the NVidia libGL.so in my app.
Help!
A11. NVidia also noticed this it seems, and the "latest" drivers
(version 4349, apparently) come with this text
DISABLING CPU SPECIFIC FEATURES
Setting the environment variable __GL_FORCE_GENERIC_CPU to a
non-zero value will inhibit the use of CPU specific features
such as MMX, SSE, or 3DNOW!. Use of this option may result in
performance loss. This option may be useful in conjunction with
software such as the Valgrind memory debugger.
Set __GL_FORCE_GENERIC_CPU=1 and Valgrind should work. This has
been confirmed by various people. Thanks NVidia!
-----------------------------------------------------------------
Q12. My program dies like this (often at exit):
VG_(mash_LD_PRELOAD_and_LD_LIBRARY_PATH): internal error:
(loads of text)
A12. We're not entirely sure about this, and would appreciate
someone sending a simple test case for us to look at.
One possible cause is that your program modifies its
environment variables, possibly including zeroing them
all. Avoid this if you can.
In any case, you may be able to work around it like this:
Comment out the
call to VG_(core_panic) at coregrind/vg_main.c:1647 and see
if that helps. The text of coregrind/vg_main.c:1647 is as follows:
VG_(core_panic)("VG_(mash_LD_PRELOAD_and_LD_LIBRARY_PATH) failed\n");
and so it's this call you want to comment out.
-----------------------------------------------------------------
Q13. My program dies like this:
error: /lib/librt.so.1: symbol __pthread_clock_settime, version
GLIBC_PRIVATE not defined in file libpthread.so.0 with link time
reference
A13. This is a total swamp. Nevertheless there is a way out.
It's a problem which is not easy to fix. Really the problem is
that /lib/librt.so.1 refers to some symbols
__pthread_clock_settime and __pthread_clock_gettime in
/lib/libpthread.so which are not intended to be exported, ie
they are private.
Best solution is to ensure your program does not use
/lib/librt.so.1.
However .. since you're probably not using it directly, or even
knowingly, that's hard to do. You might instead be able to fix
it by playing around with coregrind/vg_libpthread.vs. Things to
try:
Remove this
GLIBC_PRIVATE {
__pthread_clock_gettime;
__pthread_clock_settime;
};
or maybe remove this
GLIBC_2.2.3 {
__pthread_clock_gettime;
__pthread_clock_settime;
} GLIBC_2.2;
or maybe add this
GLIBC_2.2.4 {
__pthread_clock_gettime;
__pthread_clock_settime;
} GLIBC_2.2;
GLIBC_2.2.5 {
__pthread_clock_gettime;
__pthread_clock_settime;
} GLIBC_2.2;
or some combination of the above. After each change you need to
delete coregrind/libpthread.so and do make && make install.
I just don't know if any of the above will work. If you can
find a solution which works, I would be interested to hear it.
To which someone replied:
I deleted this:
GLIBC_2.2.3 {
__pthread_clock_gettime;
__pthread_clock_settime;
} GLIBC_2.2;
and it worked.
-----------------------------------------------------------------
(this is the end of the FAQ.)
|
|
From: Nicholas N. <nj...@ca...> - 2003-04-22 21:48:30
|
On Tue, 22 Apr 2003, Greg Hosler wrote: > 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. I just fixed it in the HEAD, thanks. N |
|
From: Madhu M. K. <mm...@ya...> - 2003-04-22 16:48:37
|
Nicholas Nethercote wrote: >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. AFAIK, Apache also does it's own mem pooling, which is why I suspect the error is not showing up. Cheerio, M Madhu M Kurup /* Nemo Me Impune Lacessit */ mmk at yahoo-inc dt com |
|
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
|