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
(17) |
2
(15) |
3
(36) |
4
(24) |
5
(36) |
|
6
(18) |
7
(16) |
8
(18) |
9
(19) |
10
(18) |
11
(37) |
12
(18) |
|
13
(13) |
14
(21) |
15
(27) |
16
(10) |
17
(16) |
18
(25) |
19
(21) |
|
20
(11) |
21
(14) |
22
(6) |
23
(15) |
24
(27) |
25
(3) |
26
(9) |
|
27
(16) |
28
(24) |
29
(21) |
30
(43) |
31
(42) |
|
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-04 23:17:51
|
On Fri, 4 Mar 2005, Jeremy Fitzhardinge wrote: > Documentation update. This should bring the core of the documentation > up to date with reality. Please give this a proofread. Looks fine, good work. > I ran out of steam at memcheck/docs/mc_techdocs.html, which is even more > hopelessly out of date. I will note that cacheprof.org is some kind of > dental insurance company now... I'd be happy if mc_techdocs.html was removed. We could point people at chapter 2 of my PhD dissertation which has a different feel, but is more up to date. N |
|
From: Jeremy F. <je...@go...> - 2005-03-04 22:38:20
|
CVS commit by fitzhardinge: Documentation update. This should bring the core of the documentation up to date with reality. Please give this a proofread. I ran out of steam at memcheck/docs/mc_techdocs.html, which is even more hopelessly out of date. I will note that cacheprof.org is some kind of dental insurance company now... M +152 -96 coregrind/docs/coregrind_core.html 1.40 M +12 -10 coregrind/docs/coregrind_intro.html 1.9 M +5 -4 docs/manual.html 1.51 M +3 -3 memcheck/docs/mc_main.html 1.16 M +8 -9 memcheck/docs/mc_techdocs.html 1.12 --- valgrind/docs/manual.html #1.50:1.51 @@ -26,12 +26,13 @@ <a name="title"> </a> -<h1 align=center>Valgrind, version 2.2.0</h1> -<center>This manual was last updated on 31 August 2004</center> +<h1 align=center>Valgrind, version 2.4.0</h1> +<center>This manual was last updated on 4 March 2005</center> <p> <center> <a href="mailto:js...@ac...">js...@ac...</a>, - <a href="mailto:nj...@ca...">nj...@ca...</a><br> -Copyright © 2000-2004 Julian Seward, Nick Nethercote + <a href="mailto:nj...@ca...">nj...@ca...</a>, +<a href="mailto:je...@go...">je...@go...</a><br> +Copyright © 2000-2005 Julian Seward, Nick Nethercote, Jeremy Fitzhardinge <p> --- valgrind/coregrind/docs/coregrind_core.html #1.39:1.40 @@ -173,5 +173,6 @@ tree of processes at once, since it means that each process writes to its own logfile, rather than the result being jumbled up in one - big logfile. + big logfile. If <code>filename.pid12345</code> already exists, then + it will name new files <code>filename.pid12345.1</code> and so on. <p> <li>The least intrusive option is to send the commentary to a network @@ -246,5 +247,5 @@ ==25832== by 0x40371E5E: __libc_start_main (libc-start.c:129) ==25832== by 0x80485D1: (within /home/sewardj/newmat10/bogon) - ==25832== Address 0xBFFFF74C is not stack'd, malloc'd or free'd + ==25832== Address 0xBFFFF74C is not stack'd, malloc'd or free'd </pre> @@ -500,5 +501,5 @@ <li><code>--help-debug</code><br> <p>Same as <code>--help</code>, but also lists debugging options which - usually are only of use to developers.</li><br><p> + usually are only of use to Valgrind's developers.</li><br><p> <li><code>--version</code><br> <p>Show the version number of the @@ -727,8 +728,8 @@ <li><code>--alignment=<number></code> [default: 8]<br> <p>By default Valgrind's <code>malloc</code>, <code>realloc</code>, - etc, return 4-byte aligned addresses. These are suitable for + etc, return 8-byte aligned addresses. These are suitable for any accesses on x86 processors. Some programs might however assume that <code>malloc</code> et - al return 8- or more aligned memory. The supplied value must be + al return 16- or more aligned memory. The supplied value must be between 4 and 4096 inclusive, and must be a power of two.</li><br><p> @@ -786,4 +787,25 @@ </li><br><p> + <li><code>--pointercheck=yes</code> [default]<br> + <code>--pointercheck=no</code> + <p> + This option make Valgrind generate a check on every memory + reference to make sure it is within the client's part of the + address space. This prevents stray writes from damaging + Valgrind itself. On x86, this uses the CPU's segmentation + machinery, and has almost no performance cost; there's almost + never a reason to turn it off. + + <li><code>--branchpred=no</code> [default]<br> + <code>--branchpred=yes</code> + <p> + This option enables the generation of static branch prediction + hints. In theory this allows the real CPU to do a better job of + running the generated code, but in practice it makes almost no + measurable difference. It may have a large effect on some x86 + implementations. Try it out; if it makes a difference for you, + put <code>--branchpred=yes</code> into your ~/.valgrindrc and + tell us about it. + <li><code>--weird-hacks=hack1,hack2,...</code> Pass miscellaneous hints to Valgrind which slightly modify the @@ -798,4 +820,12 @@ device drivers with a large number of strange ioctl commands becomes very tiresome. + <li><code>ioctl-mmap</code> Some ioctl requests can mmap new memory into + your process address space. If Valgrind doesn't know about these + mappings, it could put new mappings over them, and/or complain bitterly + when your program uses them. This option makes Valgrind scan + the address space for new mappings after each unknown ioctl has + finished. You may also need to run with <code>--pointercheck=no</code> + if the ioctl decides to place the mapping out of the client's + usual address space. </ul> </li><br><p> @@ -811,5 +841,8 @@ <p>When enabled, each x86 insn is translated separately into instrumented code. When disabled, translation is done on a - per-basic-block basis, giving much better translations.</li><br> + per-basic-block basis, giving much better translations. + This option is very useful if your program expects precise + exceptions (if it, for example, inspects or modifies register + state from within a signal handler).</li><br> <p> @@ -870,7 +903,7 @@ <p> - <li><code>--dump-error=<number></code> [default: inactive] + <li><code>--dump-error=<number></code> [default: inactive] <p>After the program has exited, show gory details of the - translation of the basic block containing the <number>'th + translation of the basic block containing the <number>'th error context. When used with <code>--single-step=yes</code>, can show the exact x86 instruction causing an error. This is @@ -925,15 +958,29 @@ Clients need to include a header file to make this work. Which header file depends on which client requests you use. Some client requests are handled by -the core, and are defined in the header file <code>valgrind.h</code>. +the core, and are defined in the header file <code>valgrind/valgrind.h</code>. Tool-specific header files are named after the tool, e.g. -<code>memcheck.h</code>. All header files can be found in the -<code>include</code> directory of wherever Valgrind was installed. +<code>valgrind/memcheck.h</code>. All header files can be found in the +<code>include/valgrind</code> directory of wherever Valgrind was installed. <p> -The macros in these header files have the magical property that -they generate code in-line which Valgrind can spot. However, the code -does nothing when not run on Valgrind, so you are not forced to run -your program on Valgrind just because you use the macros in this file. +The macros in these header files have the magical property that they +generate code in-line which Valgrind can spot. However, the code does +nothing when not run on Valgrind, so you are not forced to run your +program on Valgrind just because you use the macros in this file. Also, you are not required to link your program with any extra -supporting libraries. +supporting libraries. The code left in your binary has minimal +performance impact. +<p> +If you really wish to compile out the client requests, you can compile +with <code>-DNVALGRIND</code> (analogous to <code>-DNDEBUG</code>'s +effect on <code>assert()</code>). +<p> +You are encouraged to copy the <code>valgrind/*.h</code> headers into +your project's include directory, so your program doesn't have a +compile-time dependency on Valgrind being installed. The Valgrind +headers, unlike the rest of the code, is under a BSD-style license so +you may include them without worrying about license incompatibility. +The macros in <code>valgrind/*.h</code> will be forwards and backwards +compatible across all versions of Valgrind (from 2.0.0 onwards); at +worst a macro will do nothing. <p> Here is a brief description of the macros available in @@ -941,6 +988,8 @@ tool-specific documentation for explanations of the tool-specific macros). <ul> -<li><code>RUNNING_ON_VALGRIND</code>: returns 1 if running on - Valgrind, 0 if running on the real CPU. +<li><code>RUNNING_ON_VALGRIND</code>: returns non-zero if running on + Valgrind, 0 if running on the real CPU. If you are running + Valgrind under itself, it will return the number of layers of + Valgrind emulation we're running under. <p> <li><code>VALGRIND_DISCARD_TRANSLATIONS</code>: discard translations @@ -1023,5 +1072,5 @@ <a name="pthreads"></a> -<h3>2.8 Support for POSIX Pthreads</h3> +<h3>2.8 Support for Threads</h3> Valgrind supports programs which use POSIX pthreads. However, it runs @@ -1031,4 +1080,19 @@ apps only utilise one CPU, even if you have a multiprocessor machine. <p> +Your program will use the native <code>libpthread</code>, but not all +of its facilities will work. In particular, <strong>process-shared +synchronization WILL NOT WORK</strong>. They rely on special atomic +instruction sequences which Valgrind does not emulate in a way which +works between processes. Unfortunately there's no way for Valgrind to +warn when this is happening, and such calls will mostly work; it's +only when there's a race will it fail. +<p> +Valgrind also supports direct use of the <code>clone()</code> system +call, <code>futex()</code> and so on. <code>clone()</code> is +supported where either everything is shared (a thread) or nothing is +shared (fork-like); partial sharing will fail. Again, any use of +atomic instruction sequences in shared memory between processes will +not work. +<p> Valgrind schedules your threads in a round-robin fashion, with all threads having equal priority. It switches threads every 50000 basic @@ -1043,17 +1107,17 @@ <h3>2.9 Handling of signals</h3> -Valgrind provides suitable handling of signals, so, provided you stick -to POSIX stuff, you should be ok. Basic sigaction() and sigprocmask() -are handled. Signal handlers may return in the normal way or do -longjmp(); both should work ok. As specified by POSIX, a signal is -blocked in its own handler. Default actions for signals should work -as before. Etc, etc. - -<p>Under the hood, dealing with signals is a real pain, and Valgrind's -simulation leaves much to be desired. If your program does -way-strange stuff with signals, bad things may happen. If so, let me -know. I don't promise to fix it, but I'd at least like to be aware of -it. +<p>Valgrind has a fairly complete signal implementation. It should be +able to cope with any valid use of signals. +<p>If you're using signals in clever ways (for example, catching +SIGSEGV, modifying page state and restarting the instruction), you're +probably relying on precise exceptions. In this case, you will need +to use <code>--single-step=yes</code>. + +<p>If your program dies as a result of a fatal core-dumping signal, +Valgrind will generate its own core file +(<code>vgcore.pidNNNNN</code>) containing your program's state. You +may use this core file for post-mortem debugging with gdb or similar. +(Note: it will not generate a core if your core dump size limit is 0.) @@ -1065,6 +1129,22 @@ attempted to ensure that it works on machines with kernel 2.4 or 2.6 and glibc 2.2.X or 2.3.X. I don't think there is much else to say. -There are no options apart from the usual <code>--prefix</code> that -you should give to <code>./configure</code>. +<p>There are two options (in addition to the usual +<code>--prefix=</code> which affect how Valgrind is built: +<dl> + <dt><code>--enable-pie</code> + <dd>PIE stands for "position-independent executable". This is + enabled by default if your toolchain supports it. PIE allows + Valgrind to place itself as high as possible in memory, giving + your program as much address space as possible. It also allows + Valgrind to run under itself. If PIE is disabled, Valgrind loads + at a default address which is suitable for most systems. This is + also useful for debugging Valgrind itself. + <dt><code>--enable-tls</code> + <dd>TLS (Thread Local Storage) is a relatively new mechanism which + requires compiler, linker and kernel support. Valgrind automatically + test if TLS is supported and enable this option. Sometimes it + cannot test for TLS, so this option allows you to override the + automatic test. +</dl> <p> @@ -1125,11 +1205,7 @@ <p> - <li>Pthreads support is improving, but there are still significant - limitations in that department. See the section above on - Pthreads. Note that your program must be dynamically linked - against <code>libpthread.so</code>, so that Valgrind can - substitute its own implementation at program startup time. If - you're statically linked against it, things will fail - badly.</li> + <li>Atomic instruction sequences are not supported, which will + affect any use of synchronization objects being shared between + processes. They will appear to work, but fail sporadically.</li> <p> @@ -1152,13 +1228,4 @@ <p> - <li>Valgrind's signal simulation is not as robust as it could be. - Basic POSIX-compliant sigaction and sigprocmask functionality is - supplied, but it's conceivable that things could go badly awry - if you do weird things with signals. Workaround: don't. - Programs that do non-POSIX signal tricks are in any case - inherently unportable, so should be avoided if - possible.</li> - <p> - <li>Programs which switch stacks are not well handled. Valgrind does have support for this, but I don't have great faith in it. @@ -1221,12 +1288,5 @@ <ul> - <li>On Red Hat 7.3, there have been reports of link errors (at - program start time) for threaded programs using - <code>__pthread_clock_gettime</code> and - <code>__pthread_clock_settime</code>. This appears to be due to - <code>/lib/librt-2.2.5.so</code> needing them. Unfortunately I - do not understand enough about this problem to fix it properly, - and I can't reproduce it on my test RedHat 7.3 system. Please - mail me if you have more information / understanding. </li><br> + <li>(None)</li><br> <p> </ul> @@ -1245,38 +1305,33 @@ <h4>2.13.1 Getting started</h4> -Valgrind is compiled into a shared object, valgrind.so. The shell -script valgrind sets the LD_PRELOAD environment variable to point to -valgrind.so. This causes the .so to be loaded as an extra library to -any subsequently executed dynamically-linked ELF binary, viz, the -program you want to debug. - -<p>The dynamic linker allows each .so in the process image to have an -initialisation function which is run before main(). It also allows -each .so to have a finalisation function run after main() exits. - -<p>When valgrind.so's initialisation function is called by the dynamic -linker, the synthetic CPU to starts up. The real CPU remains locked -in valgrind.so for the entire rest of the program, but the synthetic -CPU returns from the initialisation function. Startup of the program -now continues as usual -- the dynamic linker calls all the other .so's -initialisation routines, and eventually runs main(). This all runs on -the synthetic CPU, not the real one, but the client program cannot -tell the difference. - -<p>Eventually main() exits, so the synthetic CPU calls valgrind.so's -finalisation function. Valgrind detects this, and uses it as its cue -to exit. It prints summaries of all errors detected, possibly checks -for memory leaks, and then exits the finalisation routine, but now on -the real CPU. The synthetic CPU has now lost control -- permanently --- so the program exits back to the OS on the real CPU, just as it -would have done anyway. - -<p>On entry, Valgrind switches stacks, so it runs on its own stack. -On exit, it switches back. This means that the client program -continues to run on its own stack, so we can switch back and forth -between running it on the simulated and real CPUs without difficulty. -This was an important design decision, because it makes it easy (well, -significantly less difficult) to debug the synthetic CPU. - +Valgrind is compiled into two executables: <code>valgrind</code>, and +<code>stage2</code>. <code>Valgrind</code> is a statically-linked +executable which loads at the normal address (0x8048000). +<code>Stage2</code> is a normal dynamically-linked executable; it is +either linked to load at a high address (0xb8000000) or is a Position +Independent Executable. + +<p><code>Valgrind</code> (also known as <code>stage1</code>): +<ol> +<li>Decides where to load stage2 +<li>Pads the address space with <code>mmap</code>, leaving holes only + where stage2 should load. +<li>Loads stage2 in the same manner as <code>execve()</code> would, but "manually". +<li>Jumps to the start of stage2 +</ol> + +<p>Once stage2 is loaded, it uses <code>dlopen()</code> to load the +Tool, unmaps all traces of stage1, initializes the client's state, and +starts the synthetic CPU. + +<p>Each thread runs in its own kernel thread, and loops in +<code>VG_(schedule)</code> as it runs. When the thread terminates, +<code>VG_(schedule)</code> returns. Once all the threads have +terminated, Valgrind as a whole exits. + +<p>Each thread also has two stacks. One is the client's stack, which +is manipulated with the client's instructions. The other is +Valgrind's internal stack, which is used by all Valgrind's code on +behalf of that thread. It is important to not get them confused. <a name="engine"></a> @@ -1357,7 +1412,8 @@ <h4>2.13.5 Signals</h4> -All system calls to sigaction() and sigprocmask() are intercepted. If -the client program is trying to set a signal handler, Valgrind makes a -note of the handler address and which signal it is for. Valgrind then + +All signal-related system calls are intercepted. If the client +program is trying to set a signal handler, Valgrind makes a note of +the handler address and which signal it is for. Valgrind then arranges for the same signal to be delivered to its own handler. @@ -1480,5 +1536,5 @@ Or <p> -<li> <code>Warning: noted but unhandled ioctl <number></code> +<li> <code>Warning: noted but unhandled ioctl <number></code> <br> Valgrind observed a call to one of the vast family of @@ -1488,5 +1544,5 @@ errors after this as a result of the non-update of the memory info. <p> -<li> <code>Warning: set address range perms: large range <number></code> +<li> <code>Warning: set address range perms: large range <number></code> <br> Diagnostic message, mostly for benefit of the valgrind --- valgrind/coregrind/docs/coregrind_intro.html #1.8:1.9 @@ -102,4 +102,7 @@ Fitzhardinge, and we have him to thank for getting it to a releasable state. + <p><em>Note:</em>Helgrind is not functioning in 2.4.0; we hope to + resurrect it for the next release. +<p> </ul> @@ -117,18 +120,17 @@ x86s. Valgrind uses the standard Unix <code>./configure</code>, <code>make</code>, <code>make install</code> mechanism, and we have -attempted to ensure that it works on machines with kernel 2.2 or 2.4 -and glibc 2.1.X, 2.2.X or 2.3.1. This should cover the vast majority -of modern Linux installations. Note that glibc-2.3.2+, with the -NPTL (Native Posix Threads Library) package won't work. We hope to -be able to fix this, but it won't be easy. +attempted to ensure that it works on machines with kernel 2.4 or 2.6 +and glibc 2.1.X to 2.3.X. <p> Valgrind is licensed under the GNU General Public License, version -2. Read the file LICENSE in the source distribution for details. Some -of the PThreads test cases, <code>pth_*.c</code>, are taken from -"Pthreads Programming" by Bradford Nichols, Dick Buttlar & -Jacqueline Proulx Farrell, ISBN 1-56592-115-1, published by O'Reilly -& Associates, Inc. +2. Read the file LICENSE in the source distribution for details. The +<code>valgrind/*.h</code> headers are distributed under a BSD-style +license, so you may include them in your code without worrying about +license conflicts. Some of the PThreads test cases, +<code>pth_*.c</code>, are taken from "Pthreads Programming" by +Bradford Nichols, Dick Buttlar & Jacqueline Proulx Farrell, ISBN +1-56592-115-1, published by O'Reilly & Associates, Inc. --- valgrind/memcheck/docs/mc_techdocs.html #1.11:1.12 @@ -69,13 +69,12 @@ code generator for the Glasgow Haskell Compiler (http://www.haskell.org/ghc), gaining familiarity with x86 internals -on the way. I then did Cacheprof (http://www.cacheprof.org), gaining -further x86 experience. Some time around Feb 2000 I started -experimenting with a user-space x86 interpreter for x86-Linux. This -worked, but it was clear that a JIT-based scheme would be necessary to -give reasonable performance for Valgrind. Design work for the JITter -started in earnest in Oct 2000, and by early 2001 I had an x86-to-x86 -dynamic translator which could run quite large programs. This -translator was in a sense pointless, since it did not do any -instrumentation or checking. +on the way. I then did Cacheprof, gaining further x86 experience. +Some time around Feb 2000 I started experimenting with a user-space +x86 interpreter for x86-Linux. This worked, but it was clear that a +JIT-based scheme would be necessary to give reasonable performance for +Valgrind. Design work for the JITter started in earnest in Oct 2000, +and by early 2001 I had an x86-to-x86 dynamic translator which could +run quite large programs. This translator was in a sense pointless, +since it did not do any instrumentation or checking. <p> --- valgrind/memcheck/docs/mc_main.html #1.15:1.16 @@ -165,5 +165,5 @@ by 0x40B07FF4: read_png_image__FP8QImageIO (kernel/qpngio.cpp:326) by 0x40AC751B: QImageIO::read() (kernel/qimage.cpp:3621) - Address 0xBFFFF0E0 is not stack'd, malloc'd or free'd + Address 0xBFFFF0E0 is not stack'd, malloc'd or free'd </pre> @@ -253,5 +253,5 @@ by 0x402A6E5E: __libc_start_main (libc-start.c:129) by 0x80483B1: (within tests/doublefree) - Address 0x3807F7B4 is 0 bytes inside a block of size 177 free'd + Address 0x3807F7B4 is 0 bytes inside a block of size 177 free'd at 0x4004FFDF: free (vg_clientmalloc.c:577) by 0x80484C7: main (tests/doublefree.c:10) @@ -278,5 +278,5 @@ by 0x4C261C41: PptDoc::~PptDoc(void) (include/qmemarray.h:60) by 0x4C261F0E: PptXml::~PptXml(void) (pptxml.cc:44) - Address 0x4BB292A8 is 0 bytes inside a block of size 64 alloc'd + Address 0x4BB292A8 is 0 bytes inside a block of size 64 alloc'd at 0x4004318C: __builtin_vec_new (vg_clientfuncs.c:152) by 0x4C21BC15: KLaola::readSBStream(int) const (klaola.cc:314) |
|
From: Jeremy F. <je...@go...> - 2005-03-04 22:19:26
|
At the moment, its very hard to use the VALGRIND_* macros in a program,
because doing so makes the source dependent on having valgrind
installed, and people don't like to add unnecessary dependencies to
their packages.
I think we should explicitly encourage people to include the
valgrind/*.h headers in their own source trees, and go mad scattering
Valgrind macros in their source.
This means we need to make sure any changes to the valgrind macros are
forwards and backwards compatible. We've been pretty good about this;
it just means never recycling request numbers, and only changing the
functions of a given request in compatible ways. We're helped by the
fact that all requests have 4 arguments, which are 0 if they're not
otherwise used.
I'm doing a documentation update patch now (a review of all the
documentation, not just this issue).
J
|
|
From: Jeremy F. <je...@go...> - 2005-03-04 17:08:18
|
Tom Hughes wrote:
>Obviously valgrind would have to mark the areas used by cloned
>threads as stacks, as well as the initial stack.
>
>
Maybe, though possibly not. We don't have any trouble with those stacks
at the moment. There are quite a few details to be filled out.
J
|
|
From: Jeremy F. <je...@go...> - 2005-03-04 17:07:03
|
Julian Seward wrote:
>Yes, I agree. But (1) not for 2.4.0, and (2) how does this client
>request work? The client request needs to happen atomically with
>the new assignment to the stack pointer; I don't see how that can
>happen.
>
No, I was proposing a call which you'd use at stack-allocation time, to
tell Valgrind that this is a stack, and it is distinct from all other
stacks. This would allow update_unknown_ESP (or whatever it's called)
to know whether the ESP changed from one stack area to another. It also
has the advantage of not needing to instrument every place in which the
stack switch can happen.
J
|
|
From: Tom H. <to...@co...> - 2005-03-04 15:43:52
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>> So I'd suggest implementing the client request as Jeremy says, and then
>> tweaking the heuristic so that the %esp-delta has to be substantially
>> bigger (say, 8MB) before Memcheck assumes it's a stack-switch. And add a
>> FAQ about it.
>
> Yes, I agree. But (1) not for 2.4.0, and (2) how does this client
> request work? The client request needs to happen atomically with
> the new assignment to the stack pointer; I don't see how that can
> happen.
I thought Jeremy's suggestion was to have a request that would
declare an area of memory as a stack so that valgrind would know
that when the stack pointer moved from one "stack area" to another
one then it would know it was a stack switch.
Obviously valgrind would have to mark the areas used by cloned
threads as stacks, as well as the initial stack.
I have no idea if that is all workable, but it is what I though
had been suggested anyway and it doesn't seem to require an atomic
request and update stack pointer operation.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-03-04 15:31:40
|
> Arguably the bigger problem is when Joe Programmer allocates a 2MB array > on the stack and Memcheck gives him a zillion invalid read/write errors > because it thinks he switched stacks. I think we should slant things in > favour of him, rather than the person using stack-switching -- they > presumably know what they're doing, so making them use a client request > seems not unreasonable. > > So I'd suggest implementing the client request as Jeremy says, and then > tweaking the heuristic so that the %esp-delta has to be substantially > bigger (say, 8MB) before Memcheck assumes it's a stack-switch. And add a > FAQ about it. Yes, I agree. But (1) not for 2.4.0, and (2) how does this client request work? The client request needs to happen atomically with the new assignment to the stack pointer; I don't see how that can happen. J |
|
From: Nicholas N. <nj...@cs...> - 2005-03-04 14:31:08
|
CVS commit by nethercote:
Added Aikido.
M +4 -0 users.html 1.82
--- devel-home/valgrind/users.html #1.81:1.82
@@ -240,4 +240,8 @@
<dd>An experimental OO programming language implementation, including a
structure editor.
+
+<dt><a href="http://sf.net/projects/aikido">Aikido</a>
+<dd>An interpreted prototyping and scripting language with a syntax that
+ resembles C++ and Java.
</dl>
|
|
From: Jeremy F. <je...@go...> - 2005-03-04 08:30:48
|
CVS commit by fitzhardinge:
Don't build or test helgrind for now.
M +5 -3 Makefile.am 1.75
M +1 -1 valgrind.spec.in 1.20
--- valgrind/valgrind.spec.in #1.19:1.20
@@ -36,5 +36,5 @@
/usr/include/valgrind/valgrind.h
/usr/include/valgrind/memcheck.h
-/usr/include/valgrind/helgrind.h
+#/usr/include/valgrind/helgrind.h
/usr/include/valgrind/basic_types.h
/usr/include/valgrind/tool.h
--- valgrind/Makefile.am #1.74:1.75
@@ -6,6 +6,5 @@
## include must be first for tool.h
## addrcheck must come after memcheck, for mac_*.o
-SUBDIRS = include coregrind . docs tests auxprogs \
- memcheck \
+TOOLS = memcheck \
addrcheck \
cachegrind \
@@ -15,4 +14,7 @@
none
+SUBDIRS = include coregrind . docs tests auxprogs $(TOOLS)
+DIST_SUBDIRS = $(SUBDIRS) helgrind
+
SUPP_FILES = \
glibc-2.1.supp glibc-2.2.supp glibc-2.3.supp \
@@ -32,5 +34,5 @@
## Preprend @PERL@ because tests/vg_regtest isn't executable
regtest: check
- @PERL@ tests/vg_regtest --all
+ @PERL@ tests/vg_regtest $(TOOLS)
EXTRA_DIST = \
|
|
From: Oswald B. <os...@kd...> - 2005-03-04 05:56:20
|
CVS commit by ossi:
fix update. diff -u is something wonderful ... :)
M +1 -1 coregrind_core.html 1.39
--- valgrind/coregrind/docs/coregrind_core.html #1.38:1.39
@@ -589,5 +589,5 @@
<li><code>--num-callers=<number></code> [default=12]<br>
- <p>By default, Valgrind shows four levels of function call names
+ <p>By default, Valgrind shows twelve levels of function call names
to help you identify program locations. You can change that
number with this option. This can help in determining the
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-04 05:51:37
|
CVS commit by nethercote: Remove FAQ 5.3, which is no longer true/relevant. M +0 -15 FAQ.txt 1.25 --- valgrind/FAQ.txt #1.24:1.25 @@ -315,19 +315,4 @@ way that fits with how Memcheck works. Sorry. ------------------------------------------------------------------ - -5.3. My program dies with a segmentation fault, but Memcheck doesn't give - any error messages before it, or none that look related. - -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'; - -or something similar. Writing to read-only memory can also apparently -make LinuxThreads behave strangely. - ----------------------------------------------------------------- |
|
From: Nicholas N. <nj...@cs...> - 2005-03-04 05:42:26
|
CVS commit by nethercote:
Update docs for option default changes.
M +3 -1 coregrind_core.html 1.38
--- valgrind/coregrind/docs/coregrind_core.html #1.37:1.38
@@ -488,4 +488,6 @@
</ul>
+If you omit this option, the default tool is Memcheck.
+
<h4>Basic Options</h4>
These options work with all tools.
@@ -586,5 +588,5 @@
</li><br><p>
- <li><code>--num-callers=<number></code> [default=4]<br>
+ <li><code>--num-callers=<number></code> [default=12]<br>
<p>By default, Valgrind shows four levels of function call names
to help you identify program locations. You can change that
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-04 05:37:52
|
CVS commit by nethercote:
Change things back so that suppressions still use mangled names -- maybe
we should change this, but if we do it should be documented, and the old
style should still be allowed to work.
M +2 -2 vg_errcontext.c 1.72
--- valgrind/coregrind/vg_errcontext.c #1.71:1.72
@@ -363,5 +363,5 @@ static void gen_suppression(Error* err)
if (i > 0)
eip -= MIN_INSTR_SIZE; // point to calling line
- if ( VG_(get_fnname) (eip, buf, M_VG_ERRTXT) ) {
+ if ( VG_(get_fnname_nodemangle) (eip, buf, M_VG_ERRTXT) ) {
// Stop after "main"; if main() is recursive, stop after last main().
@@ -985,5 +985,5 @@ Bool supp_matches_callers(Error* err, Su
case FunName:
// Nb: mangled names used in suppressions
- (void)VG_(get_fnname)(a, caller_name, M_VG_ERRTXT);
+ (void)VG_(get_fnname_nodemangle)(a, caller_name, M_VG_ERRTXT);
break;
default: VG_(skin_panic)("supp_matches_callers");
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-04 05:34:26
|
CVS commit by nethercote: update M +6 -5 valgrind-quick-start 1.5 --- devel-home/valgrind/valgrind-quick-start #1.4:1.5 @@ -10,5 +10,7 @@ What follows is the minimum information you need to start detecting memory -errors in your program with Memcheck. +errors in your program with Memcheck. Note that this guide applies to +Valgrind version 2.4.0; some of the information is not quite right for +earlier versions. @@ -25,9 +27,8 @@ Use this command line: - valgrind --tool=memcheck --num-callers=40 --leak-check=yes myprog arg1 arg2 + valgrind --leak-check=yes myprog arg1 arg2 -The --tool option invokes Memcheck. The --num-callers option asks for big -stack traces, which make error messages more informative. The --leak-check -option turns on the memory leak detector. +Memcheck is the default tool. The --leak-check option turns on the memory +leak detector. Your program will run much slower (eg. 20 to 30 times) than normal, and use |
|
From: Nicholas N. <nj...@cs...> - 2005-03-04 05:11:29
|
CVS commit by nethercote:
Make Memcheck the default tool again.
M +4 -24 coregrind/vg_main.c 1.261
M +1 -1 none/tests/cmdline1.stdout.exp 1.13
M +1 -1 none/tests/cmdline1.vgtest 1.2
M +1 -1 none/tests/cmdline2.stdout.exp 1.15
M +1 -1 none/tests/cmdline2.vgtest 1.2
--- valgrind/coregrind/vg_main.c #1.260:1.261
@@ -1285,13 +1285,4 @@ void VG_(bad_option) ( Char* opt )
}
-static void missing_tool_option ( void )
-{
- abort_msg();
- VG_(printf)("valgrind: Missing --tool option\n");
- list_tools();
- VG_(printf)("valgrind: Use --help for more information.\n");
- VG_(exit)(1);
-}
-
static void missing_prog ( void )
{
@@ -1476,5 +1467,5 @@ void usage ( Bool debug_help )
"\n"
" common user options for all Valgrind tools, with defaults in [ ]:\n"
-" --tool=<name> use the Valgrind tool named <name>\n"
+" --tool=<name> use the Valgrind tool named <name> [memcheck]\n"
" -h --help show this message\n"
" --help-debug show this message, plus debugging options\n"
@@ -1593,15 +1584,4 @@ static void pre_process_cmd_line_options
}
}
-
- /* If no tool specified, can act appropriately without loading tool */
- if (*tool == NULL) {
- if (0 == *need_help) {
- // neither --tool nor --help/--help-debug specified
- missing_tool_option();
- } else {
- // Give help message, without any tool-specific help
- usage(/*help-debug?*/2 == *need_help);
- }
- }
}
@@ -2350,5 +2330,5 @@ int main(int argc, char **argv, char **e
{
char **cl_argv;
- const char *tool = NULL;
+ const char *tool = "memcheck"; // default to Memcheck
const char *exec = NULL;
char *preload; /* tool-specific LD_PRELOAD .so */
@@ -2374,6 +2354,6 @@ int main(int argc, char **argv, char **e
// Command line argument handling order:
// * If --help/--help-debug are present, show usage message
- // (if --tool is also present, that includes the tool-specific usage)
- // * Then, if --tool is missing, abort with error msg
+ // (including the tool-specific usage)
+ // * (If no --tool option given, default to Memcheck)
// * Then, if client is missing, abort with error msg
// * Then, if any cmdline args are bad, abort with error msg
--- valgrind/none/tests/cmdline1.stdout.exp #1.12:1.13
@@ -2,5 +2,5 @@
common user options for all Valgrind tools, with defaults in [ ]:
- --tool=<name> use the Valgrind tool named <name>
+ --tool=<name> use the Valgrind tool named <name> [memcheck]
-h --help show this message
--help-debug show this message, plus debugging options
--- valgrind/none/tests/cmdline1.vgtest #1.1:1.2
@@ -1 +1 @@
-vgopts: --help
+vgopts: --help --tool=none
--- valgrind/none/tests/cmdline2.stdout.exp #1.14:1.15
@@ -2,5 +2,5 @@
common user options for all Valgrind tools, with defaults in [ ]:
- --tool=<name> use the Valgrind tool named <name>
+ --tool=<name> use the Valgrind tool named <name> [memcheck]
-h --help show this message
--help-debug show this message, plus debugging options
--- valgrind/none/tests/cmdline2.vgtest #1.1:1.2
@@ -1 +1 @@
-vgopts: --help-debug
+vgopts: --help-debug --tool=none
|
|
From: Nicholas N. <nj...@cs...> - 2005-03-04 04:45:18
|
CVS commit by nethercote:
Change the default --num-callers value from 4 to 12.
To support this, suppressions can now have an arbitrary number of lines in
their stack trace. Well, the maximum is a compile-time constant (currently 24,
which seems big enough), but it's no longer hard-wired to 4.
M +0 -3 coregrind/core.h 1.96
M +114 -114 coregrind/vg_errcontext.c 1.71
M +1 -1 coregrind/vg_main.c 1.260
M +4 -0 memcheck/tests/errs1.stderr.exp 1.6
M +4 -0 memcheck/tests/suppfree.stderr.exp 1.6
--- valgrind/coregrind/core.h #1.95:1.96
@@ -156,7 +156,4 @@ typedef struct _ThreadState ThreadState;
#define VG_N_RESERVED_FDS (10)
-/* Max number of callers for context in a suppression. */
-#define VG_N_SUPP_CALLERS 4
-
/* Useful macros */
/* a - alignment - must be a power of 2 */
--- valgrind/coregrind/vg_errcontext.c #1.70:1.71
@@ -127,8 +127,12 @@ typedef
CoreSuppKind;
+/* Max number of callers for context in a suppression. */
+#define VG_MAX_SUPP_CALLERS 24
+
/* For each caller specified for a suppression, record the nature of
the caller name. Not of interest to tools. */
typedef
enum {
+ NoName, /* Error case */
ObjName, /* Name is of an shared object file. */
FunName /* Name is of a function. */
@@ -136,4 +140,11 @@ typedef
SuppLocTy;
+typedef
+ struct {
+ SuppLocTy ty;
+ Char* name;
+ }
+ SuppLoc;
+
/* Suppressions. Tools can get/set tool-relevant parts with functions
declared in include/tool.h. Extensible via the 'extra' field.
@@ -144,8 +155,10 @@ struct _Supp {
Int count; // The number of times this error has been suppressed.
Char* sname; // The name by which the suppression is referred to.
- /* First two (name of fn where err occurs, and immediate caller)
- * are mandatory; extra two are optional. */
- SuppLocTy caller_ty[VG_N_SUPP_CALLERS];
- Char* caller [VG_N_SUPP_CALLERS];
+
+ // Length of 'callers'
+ Int n_callers;
+ // Array of callers, for matching stack traces. First one (name of fn
+ // where err occurs) is mandatory; rest are optional.
+ SuppLoc* callers;
/* The tool-specific part */
@@ -323,6 +336,6 @@ static void gen_suppression(Error* err)
Int stop_at = VG_(clo_backtrace_size);
- /* At most VG_N_SUPP_CALLERS names */
- if (stop_at > VG_N_SUPP_CALLERS) stop_at = VG_N_SUPP_CALLERS;
+ /* At most VG_MAX_SUPP_CALLERS names */
+ if (stop_at > VG_MAX_SUPP_CALLERS) stop_at = VG_MAX_SUPP_CALLERS;
vg_assert(stop_at > 0);
@@ -350,5 +363,5 @@ static void gen_suppression(Error* err)
if (i > 0)
eip -= MIN_INSTR_SIZE; // point to calling line
- if ( VG_(get_fnname_nodemangle) (eip, buf, M_VG_ERRTXT) ) {
+ if ( VG_(get_fnname) (eip, buf, M_VG_ERRTXT) ) {
// Stop after "main"; if main() is recursive, stop after last main().
@@ -735,14 +748,14 @@ Bool VG_(get_line) ( Int fd, Char* buf,
Returns False if failed.
*/
-static Bool setLocationTy ( Char** p_caller, SuppLocTy* p_ty )
+static Bool setLocationTy ( SuppLoc* p )
{
- if (VG_(strncmp)(*p_caller, "fun:", 4) == 0) {
- (*p_caller) += 4;
- *p_ty = FunName;
+ if (VG_(strncmp)(p->name, "fun:", 4) == 0) {
+ p->name += 4;
+ p->ty = FunName;
return True;
}
- if (VG_(strncmp)(*p_caller, "obj:", 4) == 0) {
- (*p_caller) += 4;
- *p_ty = ObjName;
+ if (VG_(strncmp)(p->name, "obj:", 4) == 0) {
+ p->name += 4;
+ p->ty = ObjName;
return True;
}
@@ -776,8 +789,10 @@ static void load_one_suppressions_file (
# define N_BUF 200
Int fd, i;
- Bool eof, too_many_contexts = False;
+ Bool eof;
Char buf[N_BUF+1];
Char* tool_names;
Char* supp_name;
+ Char* err_str = NULL;
+ SuppLoc tmp_callers[VG_MAX_SUPP_CALLERS];
fd = VG_(open)( filename, VKI_O_RDONLY, 0 );
@@ -788,4 +803,6 @@ static void load_one_suppressions_file (
}
+#define BOMB(S) { err_str = S; goto syntax_error; }
+
while (True) {
/* Assign and initialise the two suppression halves (core and tool) */
@@ -793,5 +810,11 @@ static void load_one_suppressions_file (
supp = VG_(arena_malloc)(VG_AR_CORE, sizeof(Supp));
supp->count = 0;
- for (i = 0; i < VG_N_SUPP_CALLERS; i++) supp->caller[i] = NULL;
+
+ // Initialise temporary reading-in buffer.
+ for (i = 0; i < VG_MAX_SUPP_CALLERS; i++) {
+ tmp_callers[i].ty = NoName;
+ tmp_callers[i].name = NULL;
+ }
+
supp->string = supp->extra = NULL;
@@ -799,19 +822,21 @@ static void load_one_suppressions_file (
if (eof) break;
- if (!VG_STREQ(buf, "{")) goto syntax_error;
+ if (!VG_STREQ(buf, "{")) BOMB("expected '{' or end-of-file");
eof = VG_(get_line) ( fd, buf, N_BUF );
- if (eof || VG_STREQ(buf, "}")) goto syntax_error;
+
+ if (eof || VG_STREQ(buf, "}")) BOMB("unexpected '}'");
+
supp->sname = VG_(arena_strdup)(VG_AR_CORE, buf);
eof = VG_(get_line) ( fd, buf, N_BUF );
- if (eof) goto syntax_error;
+ if (eof) BOMB("unexpected end-of-file");
- /* Check it has the "skin1,skin2,...:supp" form (look for ':') */
+ /* Check it has the "tool1,tool2,...:supp" form (look for ':') */
i = 0;
while (True) {
if (buf[i] == ':') break;
- if (buf[i] == '\0') goto syntax_error;
+ if (buf[i] == '\0') BOMB("malformed 'tool1,tool2,...:supp' line");
i++;
}
@@ -821,29 +846,27 @@ static void load_one_suppressions_file (
supp_name = & buf[i+1];
- /* Is it a core suppression? */
if (VG_(needs).core_errors && tool_name_present("core", tool_names))
{
+ // A core suppression
if (VG_STREQ(supp_name, "PThread"))
supp->skind = PThreadSupp;
else
- goto syntax_error;
+ BOMB("unknown core suppression type");
}
-
- /* Is it a tool suppression? */
else if (VG_(needs).skin_errors &&
tool_name_present(VG_(details).name, tool_names))
{
- if (SK_(recognised_suppression)(supp_name, supp))
- {
+ // A tool suppression
+ if (SK_(recognised_suppression)(supp_name, supp)) {
/* Do nothing, function fills in supp->skind */
- } else
- goto syntax_error;
+ } else {
+ BOMB("unknown tool suppression type");
+ }
}
-
else {
- /* Ignore rest of suppression */
+ // Ignore rest of suppression
while (True) {
eof = VG_(get_line) ( fd, buf, N_BUF );
- if (eof) goto syntax_error;
+ if (eof) BOMB("unexpected end-of-file");
if (VG_STREQ(buf, "}"))
break;
@@ -854,29 +877,43 @@ static void load_one_suppressions_file (
if (VG_(needs).skin_errors &&
!SK_(read_extra_suppression_info)(fd, buf, N_BUF, supp))
- goto syntax_error;
+ {
+ BOMB("bad or missing extra suppression info");
+ }
- /* "i > 0" ensures at least one caller read. */
- for (i = 0; i <= VG_N_SUPP_CALLERS; i++) {
+ i = 0;
+ while (True) {
eof = VG_(get_line) ( fd, buf, N_BUF );
- if (eof) goto syntax_error;
- if (i > 0 && VG_STREQ(buf, "}"))
+ if (eof)
+ BOMB("unexpected end-of-file");
+ if (VG_STREQ(buf, "}")) {
+ if (i > 0) {
break;
- if (i == VG_N_SUPP_CALLERS)
+ } else {
+ BOMB("missing stack trace");
+ }
+ }
+ if (i == VG_MAX_SUPP_CALLERS)
+ BOMB("too many callers in stack trace");
+ if (i > 0 && i >= VG_(clo_backtrace_size))
break;
- supp->caller[i] = VG_(arena_strdup)(VG_AR_CORE, buf);
- if (!setLocationTy(&(supp->caller[i]), &(supp->caller_ty[i])))
- goto syntax_error;
+ tmp_callers[i].name = VG_(arena_strdup)(VG_AR_CORE, buf);
+ if (!setLocationTy(&(tmp_callers[i])))
+ BOMB("location should start with 'fun:' or 'obj:'");
+ i++;
}
- /* make sure to grab the '}' if the num callers is >=
- VG_N_SUPP_CALLERS */
+ // If the num callers is >= VG_(clo_backtrace_size), ignore any extra
+ // lines and grab the '}'.
if (!VG_STREQ(buf, "}")) {
- // Don't just ignore extra lines -- abort. (Someone complained
- // about silent ignoring of lines in bug #77922.)
- //do {
- // eof = VG_(get_line) ( fd, buf, N_BUF );
- //} while (!eof && !VG_STREQ(buf, "}"));
- too_many_contexts = True;
- goto syntax_error;
+ do {
+ eof = VG_(get_line) ( fd, buf, N_BUF );
+ } while (!eof && !VG_STREQ(buf, "}"));
+ }
+
+ // Copy tmp_callers[] into supp->callers[]
+ supp->n_callers = i;
+ supp->callers = VG_(arena_malloc)(VG_AR_CORE, i*sizeof(SuppLoc));
+ for (i = 0; i < supp->n_callers; i++) {
+ supp->callers[i] = tmp_callers[i];
}
@@ -888,24 +925,12 @@ static void load_one_suppressions_file (
syntax_error:
- if (eof) {
- VG_(message)(Vg_UserMsg,
- "FATAL: in suppressions file `%s': unexpected EOF",
- filename );
- } else if (too_many_contexts) {
- VG_(message)(Vg_UserMsg,
- "FATAL: in suppressions file: `%s': at %s:",
- filename, buf );
- VG_(message)(Vg_UserMsg,
- "too many lines (limit of %d contexts in suppressions)",
- VG_N_SUPP_CALLERS);
- } else {
VG_(message)(Vg_UserMsg,
- "FATAL: in suppressions file: `%s': syntax error on: %s",
- filename, buf );
- }
+ "FATAL: in suppressions file `%s': %s", filename, err_str );
+
VG_(close)(fd);
VG_(message)(Vg_UserMsg, "exiting now.");
VG_(exit)(1);
+# undef BOMB
# undef N_BUF
}
@@ -925,17 +950,5 @@ void VG_(load_suppressions) ( void )
}
-/* Return the name of an erring fn in a way which is useful
- for comparing against the contents of a suppressions file.
- Doesn't demangle the fn name, because we want to refer to
- mangled names in the suppressions file.
-*/
-static void get_objname_fnname ( Addr a, Char* obj_buf, Int n_obj_buf,
- Char* fun_buf, Int n_fun_buf )
-{
- (void)VG_(get_objname) ( a, obj_buf, n_obj_buf );
- (void)VG_(get_fnname_nodemangle)( a, fun_buf, n_fun_buf );
-}
-
-static __inline__
+static
Bool supp_matches_error(Supp* su, Error* err)
{
@@ -956,20 +969,26 @@ Bool supp_matches_error(Supp* su, Error*
}
-static __inline__
-Bool supp_matches_callers(Supp* su, Char caller_obj[][M_VG_ERRTXT],
- Char caller_fun[][M_VG_ERRTXT])
+static
+Bool supp_matches_callers(Error* err, Supp* su)
{
Int i;
+ Char caller_name[M_VG_ERRTXT];
- for (i = 0; i < VG_N_SUPP_CALLERS && su->caller[i] != NULL; i++) {
- switch (su->caller_ty[i]) {
- case ObjName: if (VG_(string_match)(su->caller[i],
- caller_obj[i])) break;
- return False;
- case FunName: if (VG_(string_match)(su->caller[i],
- caller_fun[i])) break;
- return False;
+ for (i = 0; i < su->n_callers; i++) {
+ Addr a = err->where->ips[i];
+ vg_assert(su->callers[i].name != NULL);
+ switch (su->callers[i].ty) {
+ case ObjName:
+ (void)VG_(get_objname)(a, caller_name, M_VG_ERRTXT);
+ break;
+
+ case FunName:
+ // Nb: mangled names used in suppressions
+ (void)VG_(get_fnname)(a, caller_name, M_VG_ERRTXT);
+ break;
default: VG_(skin_panic)("supp_matches_callers");
}
+ if (!VG_(string_match)(su->callers[i].name, caller_name))
+ return False;
}
@@ -984,30 +1003,11 @@ Bool supp_matches_callers(Supp* su, Char
static Supp* is_suppressible_error ( Error* err )
{
- Int i;
-
- static Char caller_obj[VG_N_SUPP_CALLERS][M_VG_ERRTXT];
- static Char caller_fun[VG_N_SUPP_CALLERS][M_VG_ERRTXT];
-
Supp* su;
- /* get_objname_fnname() writes the function name and object name if
- it finds them in the debug info. So the strings in the suppression
- file should match these.
- */
-
- /* Initialise these strs so they are always safe to compare, even
- if get_objname_fnname doesn't write anything to them. */
- for (i = 0; i < VG_N_SUPP_CALLERS; i++)
- caller_obj[i][0] = caller_fun[i][0] = 0;
-
- for (i = 0; i < VG_N_SUPP_CALLERS && i < VG_(clo_backtrace_size); i++) {
- get_objname_fnname ( err->where->ips[i], caller_obj[i], M_VG_ERRTXT,
- caller_fun[i], M_VG_ERRTXT );
- }
-
/* See if the error context matches any suppression. */
for (su = vg_suppressions; su != NULL; su = su->next) {
if (supp_matches_error(su, err) &&
- supp_matches_callers(su, caller_obj, caller_fun)) {
+ supp_matches_callers(err, su))
+ {
return su;
}
@@ -1017,4 +1017,4 @@ static Supp* is_suppressible_error ( Err
/*--------------------------------------------------------------------*/
-/*--- end vg_errcontext.c ---*/
+/*--- end ---*/
/*--------------------------------------------------------------------*/
--- valgrind/coregrind/vg_main.c #1.259:1.260
@@ -1457,5 +1457,5 @@ Bool VG_(clo_trace_sched) = False;
Bool VG_(clo_trace_pthreads) = False;
Int VG_(clo_dump_error) = 0;
-Int VG_(clo_backtrace_size) = 4;
+Int VG_(clo_backtrace_size) = 12;
Char* VG_(clo_weird_hacks) = NULL;
Bool VG_(clo_run_libc_freeres) = True;
--- valgrind/memcheck/tests/errs1.stderr.exp #1.5:1.6
@@ -9,4 +9,6 @@
by 0x........: yyy (errs1.c:13)
by 0x........: xxx (errs1.c:14)
+ by 0x........: www (errs1.c:15)
+ by 0x........: main (errs1.c:17)
Invalid write of size 1
@@ -20,2 +22,4 @@
by 0x........: yyy (errs1.c:13)
by 0x........: xxx (errs1.c:14)
+ by 0x........: www (errs1.c:15)
+ by 0x........: main (errs1.c:17)
--- valgrind/memcheck/tests/suppfree.stderr.exp #1.5:1.6
@@ -4,4 +4,6 @@
by 0x........: ccc (suppfree.c:12)
by 0x........: bbb (suppfree.c:17)
+ by 0x........: aaa (suppfree.c:22)
+ by 0x........: main (suppfree.c:28)
Address 0x........ is 0 bytes inside a block of size 10 free'd
at 0x........: free (vg_replace_malloc.c:...)
@@ -9,2 +11,4 @@
by 0x........: ccc (suppfree.c:12)
by 0x........: bbb (suppfree.c:17)
+ by 0x........: aaa (suppfree.c:22)
+ by 0x........: main (suppfree.c:28)
|
|
From: <js...@ac...> - 2005-03-04 04:01:23
|
Nightly build on phoenix ( SuSE 9.1 ) started at 2005-03-04 03:50:00 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) helgrind/tests/toobig-allocs (stderr) helgrind/tests/x86/insn_basic (stdout) helgrind/tests/x86/insn_basic (stderr) helgrind/tests/x86/insn_cmov (stdout) helgrind/tests/x86/insn_cmov (stderr) helgrind/tests/x86/insn_fpu (stdout) helgrind/tests/x86/insn_fpu (stderr) helgrind/tests/x86/insn_mmx (stdout) helgrind/tests/x86/insn_mmx (stderr) helgrind/tests/x86/insn_sse (stdout) helgrind/tests/x86/insn_sse (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/scalar (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/writev (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <to...@co...> - 2005-03-04 03:28:22
|
Nightly build on dunsmere ( Fedora Core 3 ) started at 2005-03-04 03:20:04 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) helgrind/tests/toobig-allocs (stderr) helgrind/tests/x86/insn_basic (stdout) helgrind/tests/x86/insn_basic (stderr) helgrind/tests/x86/insn_cmov (stdout) helgrind/tests/x86/insn_cmov (stderr) helgrind/tests/x86/insn_fpu (stdout) helgrind/tests/x86/insn_fpu (stderr) helgrind/tests/x86/insn_mmx (stdout) helgrind/tests/x86/insn_mmx (stderr) helgrind/tests/x86/insn_mmxext (stdout) helgrind/tests/x86/insn_mmxext (stderr) helgrind/tests/x86/insn_sse (stdout) helgrind/tests/x86/insn_sse (stderr) memcheck/tests/scalar (stderr) memcheck/tests/scalar_supp (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-04 03:22:20
|
Nightly build on audi ( Red Hat 9 ) started at 2005-03-04 03:15:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow helgrind/tests/deadlock (stderr) helgrind/tests/inherit (stderr) helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) helgrind/tests/toobig-allocs (stderr) helgrind/tests/x86/insn_basic (stdout) helgrind/tests/x86/insn_basic (stderr) helgrind/tests/x86/insn_cmov (stdout) helgrind/tests/x86/insn_cmov (stderr) helgrind/tests/x86/insn_fpu (stdout) helgrind/tests/x86/insn_fpu (stderr) helgrind/tests/x86/insn_mmx (stdout) helgrind/tests/x86/insn_mmx (stderr) helgrind/tests/x86/insn_mmxext (stdout) helgrind/tests/x86/insn_mmxext (stderr) helgrind/tests/x86/insn_sse (stdout) helgrind/tests/x86/insn_sse (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-04 03:16:23
|
Nightly build on ginetta ( Red Hat 8.0 ) started at 2005-03-04 03:10:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow helgrind/tests/race (stderr) helgrind/tests/race2 (stderr) helgrind/tests/readshared (stderr) helgrind/tests/toobig-allocs (stderr) helgrind/tests/x86/insn_basic (stdout) helgrind/tests/x86/insn_basic (stderr) helgrind/tests/x86/insn_cmov (stdout) helgrind/tests/x86/insn_cmov (stderr) helgrind/tests/x86/insn_fpu (stdout) helgrind/tests/x86/insn_fpu (stderr) helgrind/tests/x86/insn_mmx (stdout) helgrind/tests/x86/insn_mmx (stderr) helgrind/tests/x86/insn_mmxext (stdout) helgrind/tests/x86/insn_mmxext (stderr) helgrind/tests/x86/insn_sse (stdout) helgrind/tests/x86/insn_sse (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/threadederrno (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-04 03:15:40
|
Nightly build on standard ( Red Hat 7.2 ) started at 2005-03-04 03:00:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow helgrind/tests/readshared (stderr) helgrind/tests/toobig-allocs (stderr) helgrind/tests/x86/insn_basic (stdout) helgrind/tests/x86/insn_basic (stderr) helgrind/tests/x86/insn_cmov (stdout) helgrind/tests/x86/insn_cmov (stderr) helgrind/tests/x86/insn_fpu (stdout) helgrind/tests/x86/insn_fpu (stderr) helgrind/tests/x86/insn_mmx (stdout) helgrind/tests/x86/insn_mmx (stderr) helgrind/tests/x86/insn_mmxext (stdout) helgrind/tests/x86/insn_mmxext (stderr) helgrind/tests/x86/insn_sse (stdout) helgrind/tests/x86/insn_sse (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |
|
From: Tom H. <th...@cy...> - 2005-03-04 03:11:52
|
Nightly build on alvis ( Red Hat 7.3 ) started at 2005-03-04 03:05:02 GMT Checking out source tree ... done Configuring ... done Building ... done Running regression tests ... done Last 20 lines of log.verbose follow helgrind/tests/x86/insn_mmx (stderr) helgrind/tests/x86/insn_mmxext (stdout) helgrind/tests/x86/insn_mmxext (stderr) helgrind/tests/x86/insn_sse (stdout) helgrind/tests/x86/insn_sse (stderr) massif/tests/toobig-allocs (stderr) massif/tests/true_html (stderr) massif/tests/true_text (stderr) memcheck/tests/addressable (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/pth_once (stderr) memcheck/tests/threadederrno (stderr) memcheck/tests/vgtest_ume (stderr) make: *** [regtest] Error 1 |
|
From: Bryan O'S. <bo...@se...> - 2005-03-04 00:59:42
|
On Thu, 2005-03-03 at 11:38 -0600, Nicholas Nethercote wrote: > I'm not sure what you're saying -- I described the current situation. Are > you saying my suggestion of tweaking the heuristic is bad? No, quite the opposite. <b -- Bryan O'Sullivan <bo...@se...> |
|
From: Julian S. <js...@ac...> - 2005-03-04 00:03:15
|
> The conversion would need to be per-frame rather than per ExeContext. > If you have an ExeContext of someone calling a .so, and that .so calling > something else, and then you unload the .so, you would only need to > convert the .so's frames. It is possible the ExeContext could still be > used for matching leak check records (which may only use the top 2-4 > frames). Urrrr. True. Getting more complicated by the moment. I'm not going to think about this any more just at the mo. J |