You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
|
1
(8) |
2
(8) |
3
(7) |
|
4
(3) |
5
(6) |
6
(9) |
7
(8) |
8
(7) |
9
(7) |
10
(18) |
|
11
(7) |
12
(11) |
13
(24) |
14
(13) |
15
(11) |
16
(18) |
17
(7) |
|
18
(8) |
19
(7) |
20
(9) |
21
(24) |
22
(18) |
23
(10) |
24
(7) |
|
25
(8) |
26
(11) |
27
(14) |
28
(7) |
29
(10) |
30
(7) |
|
|
From: Nicholas N. <nj...@ca...> - 2004-04-10 11:58:09
|
Hi, Background for this is http://bugs.kde.org/show_bug.cgi?id=78729. Basically, a user was confused because they accessed a free'd heap block after Valgrind had recycled it. So I propose inserting "(recently)" in the message about an address being "not stack'd, alloc'd or (recently) free'd", to make it more comprehensible what might have happened. It's a trivial code change. Any complaints about this change to error formats? I'll commit in a day or two if not. N |
|
From: Nicholas N. <nj...@ca...> - 2004-04-10 11:43:15
|
On Sat, 10 Apr 2004, Christoph Bartoschek wrote: > > Does a terminating pthread unlock all held mutexes? > No, > > http://www.opengroup.org/onlinepubs/007904975/functions/pthread_exit.html > > "Thread termination does not release any application visible process > resources, including, but not limited to, mutexes and file descriptors, nor > does it perform any process-level cleanup actions, including, but not > limited to, calling any atexit() routines that may exist." Interesting; this raises two issues. 1. Are there any legitimate reasons for a thread to not unlock a mutex before it terminates? If not, then it would be nice if Valgrind warned about such behaviour, no? Since no other thread should unlock the mutex, it will stay locked forever, AIUI. 2. Because Valgrind's libpthread recycles ThreadIds, it's possible to lock a mutex with one thread, then it dies, then another thread is spawned and it unlocks it; but the badness here is not detected because both threads have the same ThreadId. Perhaps Valgrind should not recycle ThreadIds? N |
|
From: Christoph B. <bar...@gm...> - 2004-04-10 08:20:55
|
Am Samstag, 10. April 2004 03:31 schrieb Nicholas Nethercote: > Hi, > > Does a terminating pthread unlock all held mutexes? > No, http://www.opengroup.org/onlinepubs/007904975/functions/pthread_exit.html "Thread termination does not release any application visible process resources, including, but not limited to, mutexes and file descriptors, nor does it perform any process-level cleanup actions, including, but not limited to, calling any atexit() routines that may exist." Christoph Bartoschek |
|
From: <js...@ac...> - 2004-04-10 03:07:22
|
Nightly build on phoenix ( SuSE 8.2 ) started at 2004-04-10 04:00:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 152 tests, 13 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/inherit (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: <js...@ac...> - 2004-04-10 02:41:17
|
Nightly build on nemesis ( SuSE 9.0 ) started at 2004-04-10 03:50:00 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 152 tests, 13 stderr failures, 0 stdout failures ================= corecheck/tests/as_mmap (stderr) corecheck/tests/fdleak_cmsg (stderr) corecheck/tests/fdleak_creat (stderr) corecheck/tests/fdleak_dup (stderr) corecheck/tests/fdleak_dup2 (stderr) corecheck/tests/fdleak_fcntl (stderr) corecheck/tests/fdleak_ipv4 (stderr) corecheck/tests/fdleak_open (stderr) corecheck/tests/fdleak_pipe (stderr) corecheck/tests/fdleak_socketpair (stderr) helgrind/tests/inherit (stderr) memcheck/tests/writev (stderr) memcheck/tests/zeropage (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2004-04-10 02:23:00
|
Nightly build on dunsmere ( Fedora Core 1 ) started at 2004-04-10 03:20:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow readline1: valgrind ./readline1 resolv: valgrind ./resolv seg_override: valgrind ./seg_override semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 157 tests, 1 stderr failure, 1 stdout failure ================= helgrind/tests/inherit (stderr) none/tests/exec-sigmask (stdout) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-04-10 02:18:02
|
Nightly build on audi ( Red Hat 9 ) started at 2004-04-10 03:15:03 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow readline1: valgrind ./readline1 resolv: valgrind ./resolv seg_override: valgrind ./seg_override semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 157 tests, 2 stderr failures, 0 stdout failures ================= helgrind/tests/inherit (stderr) memcheck/tests/trivialleak (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-04-10 02:13:24
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2004-04-10 03:10:02 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 157 tests, 6 stderr failures, 0 stdout failures ================= helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) memcheck/tests/nanoleak (stderr) memcheck/tests/trivialleak (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-04-10 02:08:13
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2004-04-10 03:05:03 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 157 tests, 6 stderr failures, 1 stdout failure ================= helgrind/tests/inherit (stderr) memcheck/tests/badfree-2trace (stderr) memcheck/tests/badjump (stderr) memcheck/tests/brk (stderr) memcheck/tests/error_counts (stdout) memcheck/tests/new_nothrow (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2004-04-10 02:06:35
|
Nightly build on standard ( Red Hat 7.2 ) started at 2004-04-10 03:00:03 BST Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow readline1: valgrind ./readline1 resolv: valgrind ./resolv seg_override: valgrind ./seg_override semlimit: valgrind ./semlimit sha1_test: valgrind ./sha1_test shortpush: valgrind ./shortpush shorts: valgrind ./shorts smc1: valgrind ./smc1 susphello: valgrind ./susphello syscall-restart1: valgrind ./syscall-restart1 syscall-restart2: valgrind ./syscall-restart2 system: valgrind ./system yield: valgrind ./yield -- Finished tests in none/tests ---------------------------------------- == 157 tests, 2 stderr failures, 0 stdout failures ================= helgrind/tests/inherit (stderr) memcheck/tests/badfree-2trace (stderr) make: *** [regtest] Error 1 |
|
From: Nicholas N. <nj...@ca...> - 2004-04-10 01:31:44
|
Hi, Does a terminating pthread unlock all held mutexes? Thanks. N |
|
From: Nicholas N. <nj...@ca...> - 2004-04-10 00:54:47
|
CVS commit by nethercote:
Remove "pre-history" handling for mutexes -- now that Valgrind has full control
from the very beginning (thanks to FV) it's no longer necessary.
M +0 -8 vg_include.h 1.189
M +12 -42 vg_libpthread.c 1.151
M +0 -8 vg_scheduler.c 1.146
--- valgrind/coregrind/vg_include.h #1.188:1.189
@@ -1015,12 +1015,4 @@ extern Int VG_(longjmpd_on_signal);
-/* This is or'd into a pthread mutex's __m_kind field if it is used
- before Valgrind is up and running (prehistory). This is used so
- that if some early code (like the dynamic linker) takes a lock
- before Valgrind starts and then releases it afterwards, we can work
- out what's happening. */
-#define VG_PTHREAD_PREHISTORY 0x80000000
-
-
/* ---------------------------------------------------------------------
Exports of vg_signals.c
--- valgrind/coregrind/vg_libpthread.c #1.150:1.151
@@ -1163,18 +1163,8 @@ int __pthread_mutex_lock(pthread_mutex_t
CONVERT(mutex, mutex, vg_mutex);
- if (RUNNING_ON_VALGRIND) {
VALGRIND_MAGIC_SEQUENCE(res, 0 /* default */,
VG_USERREQ__PTHREAD_MUTEX_LOCK,
vg_mutex, 0, 0, 0);
return res;
- } else {
- /* Play at locking */
- if (0)
- kludged("prehistoric lock", NULL);
- vg_mutex->__vg_m_owner = (/*_pthread_descr*/void*)1;
- vg_mutex->__vg_m_count = 1;
- vg_mutex->__vg_m_kind |= VG_PTHREAD_PREHISTORY;
- return 0; /* success */
- }
}
@@ -1186,18 +1176,8 @@ int __pthread_mutex_trylock(pthread_mute
CONVERT(mutex, mutex, vg_mutex);
- if (RUNNING_ON_VALGRIND) {
VALGRIND_MAGIC_SEQUENCE(res, 0 /* default */,
VG_USERREQ__PTHREAD_MUTEX_TRYLOCK,
vg_mutex, 0, 0, 0);
return res;
- } else {
- /* Play at locking */
- if (0)
- kludged("prehistoric trylock", NULL);
- vg_mutex->__vg_m_owner = (/*_pthread_descr*/void*)1;
- vg_mutex->__vg_m_count = 1;
- vg_mutex->__vg_m_kind |= VG_PTHREAD_PREHISTORY;
- return 0; /* success */
- }
}
@@ -1209,18 +1189,8 @@ int __pthread_mutex_unlock(pthread_mutex
CONVERT(mutex, mutex, vg_mutex);
- if (RUNNING_ON_VALGRIND) {
VALGRIND_MAGIC_SEQUENCE(res, 0 /* default */,
VG_USERREQ__PTHREAD_MUTEX_UNLOCK,
vg_mutex, 0, 0, 0);
return res;
- } else {
- /* Play at locking */
- if (0)
- kludged("prehistoric unlock", NULL);
- vg_mutex->__vg_m_owner = 0;
- vg_mutex->__vg_m_count = 0;
- vg_mutex->__vg_m_kind &= ~VG_PTHREAD_PREHISTORY;
- return 0; /* success */
- }
}
--- valgrind/coregrind/vg_scheduler.c #1.145:1.146
@@ -2150,12 +2150,4 @@ void do_pthread_mutex_unlock ( ThreadId
}
- /* If this was locked before the dawn of time, pretend it was
- locked now so that it balances with unlocks */
- if (mutex->__vg_m_kind & VG_PTHREAD_PREHISTORY) {
- mutex->__vg_m_kind &= ~VG_PTHREAD_PREHISTORY;
- VG_TRACK( pre_mutex_lock, (ThreadId)mutex->__vg_m_owner, mutex );
- VG_TRACK( post_mutex_lock, (ThreadId)mutex->__vg_m_owner, mutex );
- }
-
/* More paranoia ... */
switch (mutex->__vg_m_kind) {
|
|
From: Nicholas N. <nj...@ca...> - 2004-04-10 00:53:48
|
CVS commit by nethercote: Added 2nd expected stderr output for trivialleak; often one of the 1000 blocks by chance retains a pointer. A trivialleak.stderr.exp2 1.1 |
|
From: Nicholas N. <nj...@ca...> - 2004-04-10 00:41:59
|
CVS commit by nethercote:
Include Massif.
M +9 -0 tools.html 1.7
--- devel-home/valgrind/tools.html #1.6:1.7
@@ -56,4 +56,13 @@
about 20--100x slower than normal.
<p>
+
+<li><strong>Massif</strong> is a heap profiler. It performs detailed
+ heap profiling by taking regular snapshots of a program's heap.
+ It produces a graph showing heap usage over time, including information
+ about which parts of the program are responsible for the most memory
+ allocations. The graph is supplemented by a text or HTML file that
+ includes more information for determining where the most memory is being
+ allocated. Massif runs programs about 20x slower than normal. Massif was
+ introduced in version 2.1.1 of Valgrind.
<li><strong>Helgrind</strong> is a thread debugger which finds data races in
|
|
From: Nicholas N. <nj...@ca...> - 2004-04-10 00:36:35
|
CVS commit by nethercote: Update for having added Massif. M +2 -2 README 1.16 M +3 -3 valgrind.spec.in 1.13 --- valgrind/valgrind.spec.in #1.12:1.13 @@ -18,7 +18,7 @@ detailed profiling to help speed up your programs. -The Valgrind distribution includes four tools: two memory error -detectors, a thread error detector, and a cache profiler. Several other -tools have been built with Valgrind. +The Valgrind distribution includes five tools: two memory error +detectors, a thread error detector, a cache profiler and a heap profiler. +Several other tools have been built with Valgrind. %prep --- valgrind/README #1.15:1.16 @@ -22,6 +22,6 @@ The Valgrind distribution includes four tools: two memory error -detectors, a thread error detector, and a cache profiler. Several other -tools have been built with Valgrind. +detectors, a thread error detector, a cache profiler and a heap profiler. +Several other tools have been built with Valgrind. To give you an idea of what Valgrind tools do, when a program is run |
|
From: Nicholas N. <nj...@ca...> - 2004-04-10 00:31:01
|
CVS commit by nethercote: New FAQ. M +317 -260 faq.html 1.3 --- devel-home/valgrind/faq.html #1.2:1.3 @@ -8,13 +8,72 @@ <pre> -A mini-FAQ for valgrind, version 2.0.0 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Last revised 5 November 2003 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Valgrind FAQ, version 2.1.2 +~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Last revised 6 April 2004 +~~~~~~~~~~~~~~~~~~~~~~~~~ +1. Background +2. Compiling, installing and configuring +3. Valgrind aborts unexpectedly +4. Valgrind behaves unexpectedly +5. Memcheck doesn't find my bug +6. Miscellaneous + + +----------------------------------------------------------------- +1. Background +----------------------------------------------------------------- + +1.1. How do you pronounce "Valgrind"? + +The "Val" as in the world "value". The "grind" is pronounced with a +short 'i' -- ie. "grinned" (rhymes with "tinned") rather than "grined" +(rhymes with "find"). + +Don't feel bad: almost everyone gets it wrong at first. + +----------------------------------------------------------------- + +1.2. Where does the name "Valgrind" come from? + +From Nordic mythology. Originally (before release) the project was +named Heimdall, after the watchman of the Nordic gods. He could "see a +hundred miles by day or night, hear the grass growing, see the wool +growing on a sheep's back" (etc). This would have been a great name, +but it was already taken by a security package "Heimdal". + +Keeping with the Nordic theme, Valgrind was chosen. Valgrind is the +name of the main entrance to Valhalla (the Hall of the Chosen Slain in +Asgard). Over this entrance there resides a wolf and over it there is +the head of a boar and on it perches a huge eagle, whose eyes can see to +the far regions of the nine worlds. Only those judged worthy by the +guardians are allowed to pass through Valgrind. All others are refused +entrance. + +It's not short for "value grinder", although that's not a bad guess. + + +----------------------------------------------------------------- +2. Compiling, installing and configuring +----------------------------------------------------------------- + +2.1. When I trying building Valgrind, 'make' dies partway with an + assertion failure, something like this: make: expand.c:489: + + allocated_variable_append: Assertion + `current_variable_set_list->next != 0' failed. + +It's probably a bug in 'make'. Some, but not all, instances of version 3.79.1 +have this bug, see www.mail-archive.com/bug...@gn.../msg01658.html. Try +upgrading to a more recent version of 'make'. Alternatively, we have heard +that unsetting the CFLAGS environment variable avoids the problem. + + +----------------------------------------------------------------- +3. Valgrind aborts unexpectedly ----------------------------------------------------------------- -Q1. Programs run OK on valgrind, but at exit produce a bunch - of errors a bit like this +3.1. Programs run OK on Valgrind, but at exit produce a bunch of errors a bit + like this ==20755== Invalid read of size 4 @@ -32,355 +91,353 @@ 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. +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. +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. +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. +3.2. My (buggy) program dies like this: + valgrind: vg_malloc2.c:442 (bszW_to_pszW): + Assertion `pszW >= 0' failed. + +If Memcheck (the memory checker) 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. -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: +3.3. My program dies, printing a message like this along the way: - #define __NR_fstat64 197 + disInstr: unhandled instruction bytes: 0x66 0xF 0x2E 0x5 - 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. +Older versions did not support some x86 instructions, particularly +SSE/SSE2 instructions. Try a newer Valgrind; we now support almost all +instructions. If it still happens with newer versions, if the failing +instruction is an SSE/SSE2 instruction, you might be able to recompile +your progrma without it by using the flag -march to gcc. Either way, +let us know and we'll try to fix it. ----------------------------------------------------------------- -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. +3.4. My program dies like this: -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. + error: /lib/librt.so.1: symbol __pthread_clock_settime, version + GLIBC_PRIVATE not defined in file libpthread.so.0 with link time + reference ------------------------------------------------------------------ +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. -Q4. I'm running Red Hat Advanced Server. Valgrind always segfaults at - startup. +Best solution is to ensure your program does not use /lib/librt.so.1. -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. +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 -Q5. I try running "valgrind my_program", but my_program runs normally, - and Valgrind doesn't emit any output at all. + GLIBC_PRIVATE { + __pthread_clock_gettime; + __pthread_clock_settime; + }; -A5. Valgrind doesn't work out-of-the-box with programs that are entirely - statically linked. It does a quick test at startup, and if it detects - that the program is statically linked, it aborts with an explanation. - - This test may fail in some obscure cases, eg. if you run a script - under Valgrind and the script interpreter is statically linked. +or maybe remove this - If you still want static linking, you can ask gcc to link certain - libraries statically. Try the following options: + GLIBC_2.2.3 { + __pthread_clock_gettime; + __pthread_clock_settime; + } GLIBC_2.2; - -Wl,-Bstatic -lmyLibrary1 -lotherLibrary -Wl,-Bdynamic +or maybe add this - Just make sure you end with -Wl,-Bdynamic so that libc is dynamically - linked. + GLIBC_2.2.4 { + __pthread_clock_gettime; + __pthread_clock_settime; + } GLIBC_2.2; - If you absolutely cannot use dynamic libraries, you can try statically - linking together all the .o files in coregrind/, all the .o files of the - skin of your choice (eg. those in memcheck/), and the .o files of your - program. You'll end up with a statically linked binary that runs - permanently under Valgrind's control. Note that we haven't tested this - procedure thoroughly. + 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. -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. +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 trace child processes, use the --trace-children=yes option. +To which someone replied: - 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. + I deleted this: + GLIBC_2.2.3 { + __pthread_clock_gettime; + __pthread_clock_settime; + } GLIBC_2.2; + + and it worked. + + +----------------------------------------------------------------- +4. Valgrind behaves unexpectedly ----------------------------------------------------------------- -Q7. My threaded server process runs unbelievably slowly on - valgrind. So slowly, in fact, that at first I thought it - had completely locked up. +4.1. I try running "valgrind my_program", but my_program runs normally, + and Valgrind doesn't emit any output at all. -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. +For versions prior to 2.1.1: - Another possible cause is that versions prior to 1.9.6 - did not support threading on glibc 2.3.X systems well. - Hopefully the situation is much improved with 1.9.6. +Valgrind doesn't work out-of-the-box with programs that are entirely +statically linked. It does a quick test at startup, and if it detects +that the program is statically linked, it aborts with an explanation. + +This test may fail in some obscure cases, eg. if you run a script under +Valgrind and the script interpreter is statically linked. ------------------------------------------------------------------ +If you still want static linking, you can ask gcc to link certain +libraries statically. Try the following options: -Q8. My program dies, printing a message like this along the way: + -Wl,-Bstatic -lmyLibrary1 -lotherLibrary -Wl,-Bdynamic - disInstr: unhandled instruction bytes: 0x66 0xF 0x2E 0x5 +Just make sure you end with -Wl,-Bdynamic so that libc is dynamically +linked. -A8. Valgrind doesn't support the full x86 instruction set, although it - now supports many SSE and SSE2 instructions. If you know the - failing instruction is an SSE/SSE2 instruction, you might be able - to recompile your program without it by fiddling with the - -march=... flag(s) for gcc. In particular, get rid of - -march=pentium4 or -march=athlon if you can. Either way, let us - know and we'll try to fix it. +If you absolutely cannot use dynamic libraries, you can try statically +linking together all the .o files in coregrind/, all the .o files of the +tool of your choice (eg. those in memcheck/), and the .o files of your +program. You'll end up with a statically linked binary that runs +permanently under Valgrind's control. Note that we haven't tested this +procedure thoroughly. ------------------------------------------------------------------ -Q9. My program dies complaining that __libc_current_sigrtmin - is unimplemented. +For versions 2.1.1 and later: -A9. Should be fixed in 1.9.6. I would appreciate confirmation - of that. +Valgrind does now work with static binaries, although beware that some +of the tools won't operate as well as normal, because they have access +to less information about how the program runs. Eg. Memcheck will miss +some errors that it would otherwise find. This is because Valgrind +doesn't replace malloc() and friends with its own versions. It's best +if your program is dynamically linked with glibc. ----------------------------------------------------------------- -Q10. I upgraded to Red Hat 9 and threaded programs now act - strange / deadlock when they didn't before. +4.2. My threaded server process runs unbelievably slowly on Valgrind. + So slowly, in fact, that at first I thought it had completely + locked up. -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. +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. - 5 May 03: 1.9.6 should be significantly improved on - Red Hat 9, SuSE 8.2 and other glibc-2.3.2 systems. +Another possible cause is that versions prior to 1.9.6 did not support +threading on glibc 2.3.X systems well. Hopefully the situation is much +improved with 1.9.6 and later versions. ----------------------------------------------------------------- -Q11. I really need to use the NVidia libGL.so in my app. - Help! +4.3. My program uses the C++ STL and string classes. Valgrind + reports 'still reachable' memory leaks involving these classes + at the exit of the program, but there should be none. -A11. NVidia also noticed this it seems, and the "latest" drivers - (version 4349, apparently) come with this text +First of all: relax, it's probably not a bug, but a feature. Many +implementations of the C++ standard libraries use their own memory pool +allocators. Memory for quite a number of destructed objects is not +immediately freed and given back to the OS, but kept in the pool(s) for +later re-use. The fact that the pools are not freed at the exit() of +the program cause Valgrind to report this memory as still reachable. +The behaviour not to free pools at the exit() could be called a bug of +the library though. - DISABLING CPU SPECIFIC FEATURES +Using gcc, you can force the STL to use malloc and to free memory as +soon as possible by globally disabling memory caching. Beware! Doing +so will probably slow down your program, sometimes drastically. - 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. +- With gcc 2.91, 2.95, 3.0 and 3.1, compile all source using the STL + with -D__USE_MALLOC. Beware! This is removed from gcc starting with + version 3.3. - Set __GL_FORCE_GENERIC_CPU=1 and Valgrind should work. This has - been confirmed by various people. Thanks NVidia! +- With 3.2.2 and later, you should export the environment variable + GLIBCPP_FORCE_NEW before running your program. ------------------------------------------------------------------ +There are other ways to disable memory pooling: using the malloc_alloc +template with your objects (not portable, but should work for gcc) or +even writing your own memory allocators. But all this goes beyond the +scope of this FAQ. Start by reading +http://gcc.gnu.org/onlinedocs/libstdc++/ext/howto.html#3 if you +absolutely want to do that. But beware: -Q12. My program dies like this (often at exit): +1) there are currently changes underway for gcc which are not totally + reflected in the docs right now ("now" == 26 Apr 03) - VG_(mash_LD_PRELOAD_and_LD_LIBRARY_PATH): internal error: - (loads of text) +2) allocators belong to the more messy parts of the STL and people went + at great lengths to make it portable across platforms. Chances are + good that your solution will work on your platform, but not on + others. -A12. One possible cause is that your program modifies its - environment variables, possibly including zeroing them - all. Valgrind relies on the LD_PRELOAD, LD_LIBRARY_PATH and - VG_ARGS variables. Zeroing them will break things. +----------------------------------------------------------------------------- +4.4. The stack traces given by Memcheck (or another tool) aren't helpful. + How can I improve them? - As of 1.9.6, Valgrind only uses these variables with - --trace-children=no, when executing execve() or using the - --stop-after=yes flag. This should reduce the potential for - problems. +If they're not long enough, use --num-callers to make them longer. ------------------------------------------------------------------ +If they're not detailed enough, make sure you are compiling with -g to add +debug information. And don't strip symbol tables (programs should be +unstripped unless you run 'strip' on them; some libraries ship stripped). -Q13. My program dies like this: +Also, -fomit-frame-pointer and -fstack-check can make stack traces worse. - error: /lib/librt.so.1: symbol __pthread_clock_settime, version - GLIBC_PRIVATE not defined in file libpthread.so.0 with link time - reference +Some example sub-traces: -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. + With debug information and unstripped (best): - Best solution is to ensure your program does not use - /lib/librt.so.1. + Invalid write of size 1 + at 0x80483BF: really (malloc1.c:20) + by 0x8048370: main (malloc1.c:9) - 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: + With no debug information, unstripped: - Remove this + Invalid write of size 1 + at 0x80483BF: really (in /auto/homes/njn25/grind/head5/a.out) + by 0x8048370: main (in /auto/homes/njn25/grind/head5/a.out) - GLIBC_PRIVATE { - __pthread_clock_gettime; - __pthread_clock_settime; - }; + With no debug information, stripped: - or maybe remove this + Invalid write of size 1 + at 0x80483BF: (within /auto/homes/njn25/grind/head5/a.out) + by 0x8048370: (within /auto/homes/njn25/grind/head5/a.out) + by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so) + by 0x80482CC: (within /auto/homes/njn25/grind/head5/a.out) - GLIBC_2.2.3 { - __pthread_clock_gettime; - __pthread_clock_settime; - } GLIBC_2.2; + With debug information and -fomit-frame-pointer: - or maybe add this + Invalid write of size 1 + at 0x80483C4: really (malloc1.c:20) + by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so) + by 0x80482CC: ??? (start.S:81) - GLIBC_2.2.4 { - __pthread_clock_gettime; - __pthread_clock_settime; - } GLIBC_2.2; +----------------------------------------------------------------- +5. Memcheck doesn't find my bug +----------------------------------------------------------------- - GLIBC_2.2.5 { - __pthread_clock_gettime; - __pthread_clock_settime; - } GLIBC_2.2; +5.1. I try running "valgrind --tool=memcheck my_program" and get + Valgrind's startup message, but I don't get any errors and I know + my program has errors. + +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. - or some combination of the above. After each change you need to - delete coregrind/libpthread.so and do make && make install. +To trace child processes, use the --trace-children=yes option. - 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. +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: - To which someone replied: + valgrind-listener 12345 + +Obviously you have to start the listener process first. See the +documentation for more details. - I deleted this: +----------------------------------------------------------------- - GLIBC_2.2.3 { - __pthread_clock_gettime; - __pthread_clock_settime; - } GLIBC_2.2; +5.2. Why doesn't Memcheck find the array overruns in this program? - and it worked. + int static[5]; ------------------------------------------------------------------ + int main(void) + { + int stack[5]; -Q14. My program uses the C++ STL and string classes. Valgrind - reports 'still reachable' memory leaks involving these classes - at the exit of the program, but there should be none. + static[5] = 0; + stack [5] = 0; + + return 0; + } -A14. First of all: relax, it's probably not a bug, but a feature. - Many implementations of the C++ standard libraries use their own - memory pool allocators. Memory for quite a number of destructed - objects is not immediately freed and given back to the OS, but - kept in the pool(s) for later re-use. The fact that the pools - are not freed at the exit() of the program cause valgrind to - report this memory as still reachable. The behaviour not to - free pools at the exit() could be called a bug of the library - though. +Unfortunately, Memcheck doesn't do bounds checking on static or stack +arrays. We'd like to, but it's just not possible to do in a reasonable +way that fits with how Memcheck works. Sorry. - Using gcc, you can force the STL to use malloc and to free - memory as soon as possible by globally disabling memory caching. - Beware! Doing so will probably slow down your program, - sometimes drastically. +----------------------------------------------------------------- - - With gcc 2.91, 2.95, 3.0 and 3.1, compile all source using the - STL with -D__USE_MALLOC. Beware! This is removed from gcc - starting with version 3.3. +5.3. My program dies with a segmentation fault, but Memcheck doesn't give + any error messages before it, or none that look related. - - With 3.2.2 and later, you should export the environment - variable GLIBCPP_FORCE_NEW before running your program. +One possibility is that your program accesses to memory with +inappropriate permissions set, such as writing to read-only memory. +Maybe your program is writing to a static string like this: - There are other ways to disable memory pooling: using the - malloc_alloc template with your objects (not portable, but - should work for gcc) or even writing your own memory - allocators. But all this goes beyond the scope of this - FAQ. Start by reading - http://gcc.gnu.org/onlinedocs/libstdc++/ext/howto.html#3 - if you absolutely want to do that. But beware: + char* s = "hello"; + s[0] = 'j'; - 1) there are currently changes underway for gcc which are not - totally reflected in the docs right now - ("now" == 26 Apr 03) +or something similar. Writing to read-only memory can also apparently +make LinuxThreads behave strangely. - 2) allocators belong to the more messy parts of the STL and - people went at great lengths to make it portable across - platforms. Chances are good that your solution will work - on your platform, but not on others. ----------------------------------------------------------------- +6. Miscellaneous +----------------------------------------------------------------- -Q15. My program dies with a segmentation fault, but Valgrind doesn't give - any error messages before it, or none that look related. - -A15. The one kind of segmentation fault that Valgrind won't give any - warnings about is writes to read-only memory. Maybe your program is - writing to a static string like this: +6.1. I tried writing a suppression but it didn't work. Can you + write my suppression for me? - char* s = "hello"; - s[0] = 'j'; +Yes! Use the --gen-suppressions=yes feature to spit out suppressions +automatically for you. You can then edit them if you like, eg. +combining similar automatically generated suppressions using wildcards +like '*'. - or something similar. Writing to read-only memory can also apparently - make LinuxThreads behave strangely. +If you really want to write suppressions by hand, read the manual +carefully. Note particularly that C++ function names must be _mangled_. ----------------------------------------------------------------- -Q16. When I trying building Valgrind, 'make' dies partway with an - assertion failure, something like this: make: expand.c:489: - - allocated_variable_append: Assertion - `current_variable_set_list->next != 0' failed. - -A16. It's probably a bug in 'make'. Some, but not all, instances of - version 3.79.1 have this bug, see - www.mail-archive.com/bug...@gn.../msg01658.html. Try upgrading to a - more recent version of 'make'. +6.2. With Memcheck/Addrcheck's memory leak detector, what's the + difference between "definitely lost", "possibly lost", "still + reachable", and "suppressed"? ------------------------------------------------------------------ +The details are in section 3.6 of the manual. -Q17. I tried writing a suppression but it didn't work. Can you - write my suppression for me? +In short: -A17. Yes! Use the --gen-suppressions=yes feature to spit out - suppressions automatically for you. You can then edit them - if you like, eg. combining similar automatically generated - suppressions using wildcards like '*'. + - "definitely lost" means your program is leaking memory -- fix it! - If you really want to write suppressions by hand, read the - manual carefully. Note particularly that C++ function names - must be _mangled_. + - "possibly lost" means your program is probably leaking memory, + unless you're doing funny things with pointers. + + - "still reachable" means your program is probably ok -- it didn't + free some memory it could have. This is quite common and often + reasonable. Don't use --show-reachable=yes if you don't want to see + these reports. + + - "suppressed" means that a leak error has been suppressed. There are + some suppressions in the default suppression files. You can ignore + suppressed errors. + +----------------------------------------------------------------- +(this is the end of the FAQ.) </pre> |
|
From: Nicholas N. <nj...@ca...> - 2004-04-10 00:30:10
|
CVS commit by nethercote: Revamped. Split into sections, added stuff about the name "Valgrind" (where it comes from, pronunciation), removed some obsolete questions, added some new ones. M +315 -244 FAQ.txt 1.21 --- valgrind/FAQ.txt #1.20:1.21 @@ -1,12 +1,70 @@ +Valgrind FAQ, version 2.1.2 +~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Last revised 6 April 2004 +~~~~~~~~~~~~~~~~~~~~~~~~~ -A mini-FAQ for valgrind, version 1.9.6 -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Last revised 5 May 2003 -~~~~~~~~~~~~~~~~~~~~~~~ +1. Background +2. Compiling, installing and configuring +3. Valgrind aborts unexpectedly +4. Valgrind behaves unexpectedly +5. Memcheck doesn't find my bug +6. Miscellaneous + +----------------------------------------------------------------- +1. Background ----------------------------------------------------------------- -Q1. Programs run OK on valgrind, but at exit produce a bunch - of errors a bit like this +1.1. How do you pronounce "Valgrind"? + +The "Val" as in the world "value". The "grind" is pronounced with a +short 'i' -- ie. "grinned" (rhymes with "tinned") rather than "grined" +(rhymes with "find"). + +Don't feel bad: almost everyone gets it wrong at first. + +----------------------------------------------------------------- + +1.2. Where does the name "Valgrind" come from? + +From Nordic mythology. Originally (before release) the project was +named Heimdall, after the watchman of the Nordic gods. He could "see a +hundred miles by day or night, hear the grass growing, see the wool +growing on a sheep's back" (etc). This would have been a great name, +but it was already taken by a security package "Heimdal". + +Keeping with the Nordic theme, Valgrind was chosen. Valgrind is the +name of the main entrance to Valhalla (the Hall of the Chosen Slain in +Asgard). Over this entrance there resides a wolf and over it there is +the head of a boar and on it perches a huge eagle, whose eyes can see to +the far regions of the nine worlds. Only those judged worthy by the +guardians are allowed to pass through Valgrind. All others are refused +entrance. + +It's not short for "value grinder", although that's not a bad guess. + + +----------------------------------------------------------------- +2. Compiling, installing and configuring +----------------------------------------------------------------- + +2.1. When I trying building Valgrind, 'make' dies partway with an + assertion failure, something like this: make: expand.c:489: + + allocated_variable_append: Assertion + `current_variable_set_list->next != 0' failed. + +It's probably a bug in 'make'. Some, but not all, instances of version 3.79.1 +have this bug, see www.mail-archive.com/bug...@gn.../msg01658.html. Try +upgrading to a more recent version of 'make'. Alternatively, we have heard +that unsetting the CFLAGS environment variable avoids the problem. + + +----------------------------------------------------------------- +3. Valgrind aborts unexpectedly +----------------------------------------------------------------- + +3.1. Programs run OK on Valgrind, but at exit produce a bunch of errors a bit + like this ==20755== Invalid read of size 4 @@ -24,336 +82,349 @@ 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. +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. - 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. - ------------------------------------------------------------------ +Problem is that running __libc_freeres() in older glibc versions causes +this crash. -Q2. [Question erased, as it is no longer relevant] +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. ----------------------------------------------------------------- -Q3. My (buggy) program dies like this: +3.2. 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. +If Memcheck (the memory checker) 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. +3.3. My program dies, printing a message like this along the way: -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. + disInstr: unhandled instruction bytes: 0x66 0xF 0x2E 0x5 + +Older versions did not support some x86 instructions, particularly +SSE/SSE2 instructions. Try a newer Valgrind; we now support almost all +instructions. If it still happens with newer versions, if the failing +instruction is an SSE/SSE2 instruction, you might be able to recompile +your progrma without it by using the flag -march to gcc. Either way, +let us know and we'll try to fix it. ----------------------------------------------------------------- -Q5. I try running "valgrind my_program", but my_program runs normally, - and Valgrind doesn't emit any output at all. +3.4. My program dies like this: -A5. Valgrind doesn't work out-of-the-box with programs that are entirely - statically linked. It does a quick test at startup, and if it detects - that the program is statically linked, it aborts with an explanation. - - This test may fail in some obscure cases, eg. if you run a script - under Valgrind and the script interpreter is statically linked. + error: /lib/librt.so.1: symbol __pthread_clock_settime, version + GLIBC_PRIVATE not defined in file libpthread.so.0 with link time + reference - If you still want static linking, you can ask gcc to link certain - libraries statically. Try the following options: +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. - -Wl,-Bstatic -lmyLibrary1 -lotherLibrary -Wl,-Bdynamic +Best solution is to ensure your program does not use /lib/librt.so.1. - Just make sure you end with -Wl,-Bdynamic so that libc is dynamically - linked. +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: - If you absolutely cannot use dynamic libraries, you can try statically - linking together all the .o files in coregrind/, all the .o files of the - tool of your choice (eg. those in memcheck/), and the .o files of your - program. You'll end up with a statically linked binary that runs - permanently under Valgrind's control. Note that we haven't tested this - procedure thoroughly. +Remove this ------------------------------------------------------------------ + GLIBC_PRIVATE { + __pthread_clock_gettime; + __pthread_clock_settime; + }; -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. +or maybe remove this - To trace child processes, use the --trace-children=yes option. + GLIBC_2.2.3 { + __pthread_clock_gettime; + __pthread_clock_settime; + } GLIBC_2.2; - 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. +or maybe add this ------------------------------------------------------------------ + GLIBC_2.2.4 { + __pthread_clock_gettime; + __pthread_clock_settime; + } GLIBC_2.2; -Q7. My threaded server process runs unbelievably slowly on - valgrind. So slowly, in fact, that at first I thought it - had completely locked up. + GLIBC_2.2.5 { + __pthread_clock_gettime; + __pthread_clock_settime; + } GLIBC_2.2; -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. +or some combination of the above. After each change you need to delete +coregrind/libpthread.so and do make && make install. - Another possible cause is that versions prior to 1.9.6 - did not support threading on glibc 2.3.X systems well. - Hopefully the situation is much improved with 1.9.6. +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: -Q8. My program dies, printing a message like this along the way: + I deleted this: - disInstr: unhandled instruction bytes: 0x66 0xF 0x2E 0x5 + GLIBC_2.2.3 { + __pthread_clock_gettime; + __pthread_clock_settime; + } GLIBC_2.2; + + and it worked. -A8. Valgrind doesn't support the full x86 instruction set, although - it now supports many SSE and SSE2 instructions. If you know - the failing instruction is an SSE/SSE2 instruction, you might - be able to recompile your progrma without it by using the flag - -march to gcc. Either way, let us know and we'll try to fix it. ----------------------------------------------------------------- +4. Valgrind behaves unexpectedly +----------------------------------------------------------------- -Q9. My program dies complaining that __libc_current_sigrtmin - is unimplemented. +4.1. I try running "valgrind my_program", but my_program runs normally, + and Valgrind doesn't emit any output at all. -A9. Should be fixed in 1.9.6. I would appreciate confirmation - of that. +For versions prior to 2.1.1: ------------------------------------------------------------------ +Valgrind doesn't work out-of-the-box with programs that are entirely +statically linked. It does a quick test at startup, and if it detects +that the program is statically linked, it aborts with an explanation. + +This test may fail in some obscure cases, eg. if you run a script under +Valgrind and the script interpreter is statically linked. -Q10. I upgraded to Red Hat 9 and threaded programs now act - strange / deadlock when they didn't before. +If you still want static linking, you can ask gcc to link certain +libraries statically. Try the following options: -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. + -Wl,-Bstatic -lmyLibrary1 -lotherLibrary -Wl,-Bdynamic - 5 May 03: 1.9.6 should be significantly improved on - Red Hat 9, SuSE 8.2 and other glibc-2.3.2 systems. +Just make sure you end with -Wl,-Bdynamic so that libc is dynamically +linked. ------------------------------------------------------------------ +If you absolutely cannot use dynamic libraries, you can try statically +linking together all the .o files in coregrind/, all the .o files of the +tool of your choice (eg. those in memcheck/), and the .o files of your +program. You'll end up with a statically linked binary that runs +permanently under Valgrind's control. Note that we haven't tested this +procedure thoroughly. -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 +For versions 2.1.1 and later: - DISABLING CPU SPECIFIC FEATURES +Valgrind does now work with static binaries, although beware that some +of the tools won't operate as well as normal, because they have access +to less information about how the program runs. Eg. Memcheck will miss +some errors that it would otherwise find. This is because Valgrind +doesn't replace malloc() and friends with its own versions. It's best +if your program is dynamically linked with glibc. - 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! +4.2. My threaded server process runs unbelievably slowly on Valgrind. + So slowly, in fact, that at first I thought it had completely + locked up. ------------------------------------------------------------------ +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. -Q12. My program dies like this (often at exit): +Another possible cause is that versions prior to 1.9.6 did not support +threading on glibc 2.3.X systems well. Hopefully the situation is much +improved with 1.9.6 and later versions. - VG_(mash_LD_PRELOAD_and_LD_LIBRARY_PATH): internal error: - (loads of text) +----------------------------------------------------------------- -A12. One possible cause is that your program modifies its - environment variables, possibly including zeroing them - all. Valgrind relies on the LD_PRELOAD, LD_LIBRARY_PATH and - VG_ARGS variables. Zeroing them will break things. +4.3. My program uses the C++ STL and string classes. Valgrind + reports 'still reachable' memory leaks involving these classes + at the exit of the program, but there should be none. - As of 1.9.6, Valgrind only uses these variables with - --trace-children=no or when executing execve(). This should - reduce the potential for problems. +First of all: relax, it's probably not a bug, but a feature. Many +implementations of the C++ standard libraries use their own memory pool +allocators. Memory for quite a number of destructed objects is not +immediately freed and given back to the OS, but kept in the pool(s) for +later re-use. The fact that the pools are not freed at the exit() of +the program cause Valgrind to report this memory as still reachable. +The behaviour not to free pools at the exit() could be called a bug of +the library though. ------------------------------------------------------------------ +Using gcc, you can force the STL to use malloc and to free memory as +soon as possible by globally disabling memory caching. Beware! Doing +so will probably slow down your program, sometimes drastically. -Q13. My program dies like this: +- With gcc 2.91, 2.95, 3.0 and 3.1, compile all source using the STL + with -D__USE_MALLOC. Beware! This is removed from gcc starting with + version 3.3. - error: /lib/librt.so.1: symbol __pthread_clock_settime, version - GLIBC_PRIVATE not defined in file libpthread.so.0 with link time - reference +- With 3.2.2 and later, you should export the environment variable + GLIBCPP_FORCE_NEW before running your program. -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. +There are other ways to disable memory pooling: using the malloc_alloc +template with your objects (not portable, but should work for gcc) or +even writing your own memory allocators. But all this goes beyond the +scope of this FAQ. Start by reading +http://gcc.gnu.org/onlinedocs/libstdc++/ext/howto.html#3 if you +absolutely want to do that. But beware: - Best solution is to ensure your program does not use - /lib/librt.so.1. +1) there are currently changes underway for gcc which are not totally + reflected in the docs right now ("now" == 26 Apr 03) - 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: +2) allocators belong to the more messy parts of the STL and people went + at great lengths to make it portable across platforms. Chances are + good that your solution will work on your platform, but not on + others. - Remove this +----------------------------------------------------------------------------- +4.4. The stack traces given by Memcheck (or another tool) aren't helpful. + How can I improve them? - GLIBC_PRIVATE { - __pthread_clock_gettime; - __pthread_clock_settime; - }; +If they're not long enough, use --num-callers to make them longer. - or maybe remove this +If they're not detailed enough, make sure you are compiling with -g to add +debug information. And don't strip symbol tables (programs should be +unstripped unless you run 'strip' on them; some libraries ship stripped). - GLIBC_2.2.3 { - __pthread_clock_gettime; - __pthread_clock_settime; - } GLIBC_2.2; +Also, -fomit-frame-pointer and -fstack-check can make stack traces worse. - or maybe add this +Some example sub-traces: - GLIBC_2.2.4 { - __pthread_clock_gettime; - __pthread_clock_settime; - } GLIBC_2.2; + With debug information and unstripped (best): - GLIBC_2.2.5 { - __pthread_clock_gettime; - __pthread_clock_settime; - } GLIBC_2.2; + Invalid write of size 1 + at 0x80483BF: really (malloc1.c:20) + by 0x8048370: main (malloc1.c:9) - or some combination of the above. After each change you need to - delete coregrind/libpthread.so and do make && make install. + With no debug information, unstripped: - 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. + Invalid write of size 1 + at 0x80483BF: really (in /auto/homes/njn25/grind/head5/a.out) + by 0x8048370: main (in /auto/homes/njn25/grind/head5/a.out) - To which someone replied: + With no debug information, stripped: - I deleted this: + Invalid write of size 1 + at 0x80483BF: (within /auto/homes/njn25/grind/head5/a.out) + by 0x8048370: (within /auto/homes/njn25/grind/head5/a.out) + by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so) + by 0x80482CC: (within /auto/homes/njn25/grind/head5/a.out) - GLIBC_2.2.3 { - __pthread_clock_gettime; - __pthread_clock_settime; - } GLIBC_2.2; + With debug information and -fomit-frame-pointer: - and it worked. + Invalid write of size 1 + at 0x80483C4: really (malloc1.c:20) + by 0x42015703: __libc_start_main (in /lib/tls/libc-2.3.2.so) + by 0x80482CC: ??? (start.S:81) ----------------------------------------------------------------- +5. Memcheck doesn't find my bug +----------------------------------------------------------------- + +5.1. I try running "valgrind --tool=memcheck my_program" and get + Valgrind's startup message, but I don't get any errors and I know + my program has errors. + +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. -Q14. My program uses the C++ STL and string classes. Valgrind - reports 'still reachable' memory leaks involving these classes - at the exit of the program, but there should be none. +To trace child processes, use the --trace-children=yes option. -A14. First of all: relax, it's probably not a bug, but a feature. - Many implementations of the C++ standard libraries use their own - memory pool allocators. Memory for quite a number of destructed - objects is not immediately freed and given back to the OS, but - kept in the pool(s) for later re-use. The fact that the pools - are not freed at the exit() of the program cause valgrind to - report this memory as still reachable. The behaviour not to - free pools at the exit() could be called a bug of the library - though. +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: - Using gcc, you can force the STL to use malloc and to free - memory as soon as possible by globally disabling memory caching. - Beware! Doing so will probably slow down your program, - sometimes drastically. + valgrind-listener 12345 + +Obviously you have to start the listener process first. See the +documentation for more details. + +----------------------------------------------------------------- - - With gcc 2.91, 2.95, 3.0 and 3.1, compile all source using the - STL with -D__USE_MALLOC. Beware! This is removed from gcc - starting with version 3.3. +5.2. Why doesn't Memcheck find the array overruns in this program? - - With 3.2.2 and later, you should export the environment - variable GLIBCPP_FORCE_NEW before running your program. + int static[5]; - There are other ways to disable memory pooling: using the - malloc_alloc template with your objects (not portable, but - should work for gcc) or even writing your own memory - allocators. But all this goes beyond the scope of this - FAQ. Start by reading - http://gcc.gnu.org/onlinedocs/libstdc++/ext/howto.html#3 - if you absolutely want to do that. But beware: + int main(void) + { + int stack[5]; - 1) there are currently changes underway for gcc which are not - totally reflected in the docs right now - ("now" == 26 Apr 03) + static[5] = 0; + stack [5] = 0; + + return 0; + } - 2) allocators belong to the more messy parts of the STL and - people went at great lengths to make it portable across - platforms. Chances are good that your solution will work - on your platform, but not on others. +Unfortunately, Memcheck doesn't do bounds checking on static or stack +arrays. We'd like to, but it's just not possible to do in a reasonable +way that fits with how Memcheck works. Sorry. ----------------------------------------------------------------- -Q15. My program dies with a segmentation fault, but Valgrind doesn't give - any error messages before it, or none that look related. +5.3. My program dies with a segmentation fault, but Memcheck doesn't give + any error messages before it, or none that look related. -A15. The one kind of segmentation fault that Valgrind won't give any - warnings about is writes to read-only memory. Maybe your program is - writing to a static string like this: +One possibility is that your program accesses to memory with +inappropriate permissions set, such as writing to read-only memory. +Maybe your program is writing to a static string like this: - char* s = "hello"; - s[0] = 'j'; + char* s = "hello"; + s[0] = 'j'; - or something similar. Writing to read-only memory can also apparently - make LinuxThreads behave strangely. +or something similar. Writing to read-only memory can also apparently +make LinuxThreads behave strangely. + +----------------------------------------------------------------- +6. Miscellaneous ----------------------------------------------------------------- -Q16. When I trying building Valgrind, 'make' dies partway with an - assertion failure, something like this: make: expand.c:489: - - allocated_variable_append: Assertion - `current_variable_set_list->next != 0' failed. - -A16. It's probably a bug in 'make'. Some, but not all, instances of - version 3.79.1 have this bug, see - www.mail-archive.com/bug...@gn.../msg01658.html. Try upgrading to a - more recent version of 'make'. Alternatively, we have heard that - unsetting the CFLAGS environment variable avoids the problem. +6.1. I tried writing a suppression but it didn't work. Can you + write my suppression for me? + +Yes! Use the --gen-suppressions=yes feature to spit out suppressions +automatically for you. You can then edit them if you like, eg. +combining similar automatically generated suppressions using wildcards +like '*'. + +If you really want to write suppressions by hand, read the manual +carefully. Note particularly that C++ function names must be _mangled_. ----------------------------------------------------------------- -Q17. I tried writing a suppression but it didn't work. Can you - write my suppression for me? +6.2. With Memcheck/Addrcheck's memory leak detector, what's the + difference between "definitely lost", "possibly lost", "still + reachable", and "suppressed"? + +The details are in section 3.6 of the manual. + +In short: + + - "definitely lost" means your program is leaking memory -- fix it! + + - "possibly lost" means your program is probably leaking memory, + unless you're doing funny things with pointers. -A17. Yes! Use the --gen-suppressions=yes feature to spit out - suppressions automatically for you. You can then edit them - if you like, eg. combining similar automatically generated - suppressions using wildcards like '*'. + - "still reachable" means your program is probably ok -- it didn't + free some memory it could have. This is quite common and often + reasonable. Don't use --show-reachable=yes if you don't want to see + these reports. - If you really want to write suppressions by hand, read the - manual carefully. Note particularly that C++ function names - must be _mangled_. + - "suppressed" means that a leak error has been suppressed. There are + some suppressions in the default suppression files. You can ignore + suppressed errors. ----------------------------------------------------------------- |
|
From: Nicholas N. <nj...@ca...> - 2004-04-10 00:26:18
|
CVS commit by nethercote:
Added acct() syscall.
M +8 -0 vg_syscalls.c 1.93
--- valgrind/coregrind/vg_syscalls.c #1.92:1.93
@@ -4969,4 +4969,11 @@ POST(futex)
}
+PRE(acct)
+{
+ /* int acct(const char *filename); */
+ MAYBE_PRINTF("acct ( %p )\n", arg1);
+ SYSCALL_TRACK( pre_mem_read_asciiz, tid, "acct(filename)", arg1 );
+}
+
#define SIGNAL_SIMULATION 1
@@ -5374,4 +5381,5 @@ static const struct sys_info sys_info[]
SYSBA(clock_gettime, False),
SYSBA(futex, True),
+ SYSB_(acct, False),
/* new signal handling makes these normal blocking syscalls */
|