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
(3) |
|
2
(8) |
3
(19) |
4
(24) |
5
(23) |
6
(16) |
7
(33) |
8
(5) |
|
9
(4) |
10
(23) |
11
(22) |
12
(40) |
13
(30) |
14
(31) |
15
(17) |
|
16
(18) |
17
(20) |
18
(41) |
19
(36) |
20
(25) |
21
(8) |
22
(9) |
|
23
(17) |
24
(12) |
25
(15) |
26
(15) |
27
(16) |
28
(22) |
29
(6) |
|
30
(7) |
31
(10) |
|
|
|
|
|
|
From: Stuart W. <de...@ra...> - 2009-08-16 23:30:39
|
Hi Nicholas, Thanks for your patience. I'm working on an embedded application that only restarts when it is power cycled. It has to do a lot with limited memory and uses dozens of memory arenas with different lifetimes. Arenas are set up and torn down hundreds of times during the lifetime of the application. As such, it only makes sense to report leaks as each arena is torn down. Just like it makes sense to report malloc leaks when its lifetime ends. > > VALGRIND_DO_LEAK_CHECK and --leak-check both look for leaks in all > > current memory pools. I don't know why you think this is not the > > case. memcheck/tests/mempool.c makes it clear -- for example, x1 and > > x2 are leaked. > > > I understand and am not saying to the contrary. As you say VALGRIND_DO_LEAK_CHECK reports leaks for _all_ pools. In my case the leak report is only helpful if it can target leaks from a specific mempool. > > But, as you've been told, if you destroy a mempool all the chunks > > within it are freed, and so there can be no leaks from that mempool. > > That's why x3 and x4 aren't reported as leaked, because they've been > > freed. > > > Sure there are no leaks when it is destroyed, but if I have a 1MB arena that makes 2MB of allocations over its lifetime, leaks during the arena's lifetime become a problem. I have no problem with the test case. I made the mistake of using the test case to try and and explain my point....and failed miserably. Unfortunately the mempool documentation doesn't say how leak checking should work for mempools, but it does say it doesn't make any assumptions about how custom allocators should work. > > I think you should read the documentation again and try writing some > > small test programs to improve your understanding. > > > I'll go back and read through the documentation. Thanks for the suggestion. Cheers, Stu > > NIck > > > > ------------------------------------------------------------------------------ > > Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day > > trial. Simplify your report design, integration and deployment - and focus on > > what you do best, core application coding. Discover what's new with > > Crystal Reports now. http://p.sf.net/sfu/bobj-july > > _______________________________________________ > > Valgrind-developers mailing list > > Val...@li... > > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > > > > > |
|
From: <sv...@va...> - 2009-08-16 23:23:03
|
Author: sewardj Date: 2009-08-17 00:22:51 +0100 (Mon, 17 Aug 2009) New Revision: 10834 Log: First tarball-test point for 3.5.0. Modified: trunk/configure.in Modified: trunk/configure.in =================================================================== --- trunk/configure.in 2009-08-16 23:01:41 UTC (rev 10833) +++ trunk/configure.in 2009-08-16 23:22:51 UTC (rev 10834) @@ -8,7 +8,7 @@ ##------------------------------------------------------------## # Process this file with autoconf to produce a configure script. -AC_INIT(Valgrind, 3.5.0.SVN, val...@li...) +AC_INIT(Valgrind, 3.5.0-TEST1, val...@li...) AC_CONFIG_SRCDIR(coregrind/m_main.c) AM_CONFIG_HEADER(config.h) AM_INIT_AUTOMAKE([foreign]) |
|
From: <sv...@va...> - 2009-08-16 23:01:50
|
Author: sewardj Date: 2009-08-17 00:01:41 +0100 (Mon, 17 Aug 2009) New Revision: 10833 Log: Bump version. Modified: trunk/docs/xml/vg-entities.xml Modified: trunk/docs/xml/vg-entities.xml =================================================================== --- trunk/docs/xml/vg-entities.xml 2009-08-16 22:56:53 UTC (rev 10832) +++ trunk/docs/xml/vg-entities.xml 2009-08-16 23:01:41 UTC (rev 10833) @@ -6,8 +6,8 @@ <!-- valgrind release + version stuff --> <!ENTITY rel-type "Release"> -<!ENTITY rel-version "3.4.0"> -<!ENTITY rel-date "2 January 2009"> +<!ENTITY rel-version "3.5.0"> +<!ENTITY rel-date "20 August 2009"> <!-- where the docs are installed --> <!ENTITY vg-docs-path "$INSTALL/share/doc/valgrind/html/index.html"> |
|
From: <sv...@va...> - 2009-08-16 23:01:35
|
Author: sewardj
Date: 2009-08-16 23:52:29 +0100 (Sun, 16 Aug 2009)
New Revision: 10831
Log:
Increase the maximum size of the conflict cache even more, to 30
million.
Modified:
trunk/helgrind/hg_main.c
trunk/helgrind/libhb_core.c
Modified: trunk/helgrind/hg_main.c
===================================================================
--- trunk/helgrind/hg_main.c 2009-08-16 22:49:53 UTC (rev 10830)
+++ trunk/helgrind/hg_main.c 2009-08-16 22:52:29 UTC (rev 10831)
@@ -4397,10 +4397,10 @@
else if VG_XACT_CLO(arg, "--history-level=full",
HG_(clo_history_level), 2);
- /* If you change the 10k/20mill limits, remember to also change
+ /* If you change the 10k/30mill limits, remember to also change
them in assertions at the top of event_map_maybe_GC. */
else if VG_BINT_CLO(arg, "--conflict-cache-size",
- HG_(clo_conflict_cache_size), 10*1000, 20*1000*1000) {}
+ HG_(clo_conflict_cache_size), 10*1000, 30*1000*1000) {}
/* "stuvwx" --> stuvwx (binary) */
else if VG_STR_CLO(arg, "--hg-sanity-flags", tmp_str) {
Modified: trunk/helgrind/libhb_core.c
===================================================================
--- trunk/helgrind/libhb_core.c 2009-08-16 22:49:53 UTC (rev 10830)
+++ trunk/helgrind/libhb_core.c 2009-08-16 22:52:29 UTC (rev 10831)
@@ -3797,7 +3797,7 @@
/* Check for sane command line params. Limit values must match
those in hg_process_cmd_line_option. */
tl_assert( HG_(clo_conflict_cache_size) >= 10*1000 );
- tl_assert( HG_(clo_conflict_cache_size) <= 20*1000*1000 );
+ tl_assert( HG_(clo_conflict_cache_size) <= 30*1000*1000 );
/* Check our counting is sane (expensive) */
if (CHECK_CEM)
|
|
From: <sv...@va...> - 2009-08-16 22:57:09
|
Author: sewardj Date: 2009-08-16 23:56:53 +0100 (Sun, 16 Aug 2009) New Revision: 10832 Log: Comment that we never actually expect to see the string ]]> in a generated suppression, and hence the problem of having to split it into multiple CDATA blocks is moot. Modified: trunk/docs/internals/xml-output-protocol4.txt Modified: trunk/docs/internals/xml-output-protocol4.txt =================================================================== --- trunk/docs/internals/xml-output-protocol4.txt 2009-08-16 22:52:29 UTC (rev 10831) +++ trunk/docs/internals/xml-output-protocol4.txt 2009-08-16 22:56:53 UTC (rev 10832) @@ -318,7 +318,15 @@ why the spec calls for one or more CDATA blocks rather than exactly one. +Note that, so far, we cannot envisage a circumstance in which a +generated suppression would contain the string "]]>", since neither +"]" nor ">" appear to turn up in mangled symbol names. Hence it is +not envisaged that there will ever be more than one CDATA block, and +indeed the implementation as of Valgrind 3.5.0 will only ever generate +one block (it ignores any possible escaping problems). Nevertheless +the specification allows multiple blocks, as a matter of safety. + SFRAME ------ Either |
|
From: <sv...@va...> - 2009-08-16 22:56:40
|
Author: sewardj
Date: 2009-08-16 23:47:02 +0100 (Sun, 16 Aug 2009)
New Revision: 10829
Log:
Update the Helgrind manual for 3.5.0.
Modified:
trunk/helgrind/docs/hg-manual.xml
Modified: trunk/helgrind/docs/hg-manual.xml
===================================================================
--- trunk/helgrind/docs/hg-manual.xml 2009-08-16 01:48:35 UTC (rev 10828)
+++ trunk/helgrind/docs/hg-manual.xml 2009-08-16 22:47:02 UTC (rev 10829)
@@ -22,7 +22,8 @@
<para>The main abstractions in POSIX pthreads are: a set of threads
sharing a common address space, thread creation, thread joining,
thread exit, mutexes (locks), condition variables (inter-thread event
-notifications), reader-writer locks, semaphores and barriers.</para>
+notifications), reader-writer locks, spinlocks, semaphores and
+barriers.</para>
<para>Helgrind can detect three classes of errors, which are discussed
in detail in the next three sections:</para>
@@ -49,15 +50,21 @@
timing-dependent crashes, deadlocks and other misbehaviour, and
can be difficult to find by other means.</para>
-<para>Helgrind is aware of all the pthread abstractions and tracks their
-effects as accurately as it can. Currently it does not correctly
-handle pthread spinlocks, although it will not object if you use them.
-Adding support for spinlocks would be easy enough if the demand arises.
-On x86 and amd64 platforms, it understands and partially handles
-implicit locking arising from the use of the LOCK instruction prefix.
+<para>Helgrind is aware of all the pthread abstractions and tracks
+their effects as accurately as it can. On x86 and amd64 platforms, it
+understands and partially handles implicit locking arising from the
+use of the LOCK instruction prefix.
</para>
+<para>Helgrind works best when your application uses only the POSIX
+pthreads API. However, if you want to use custom threading
+primitives, you can describe their behaviour to Helgrind using the
+<varname>ANNOTATE_*</varname> macros defined
+in <varname>helgrind.h</varname>. This functionality was added in
+release 3.5.0 of Valgrind, and is considered experimental.</para>
+
+
<para>Following those is a section containing
<link linkend="hg-manual.effective-use">
hints and tips on how to get the best out of Helgrind.</link>
@@ -107,6 +114,8 @@
with a not-locked mutex, an invalid mutex,
or one locked by a different
thread</para></listitem>
+ <listitem><para>inconsistent bindings between condition
+ variables and their associated mutexes</para></listitem>
<listitem><para>invalid or duplicate initialisation of a pthread
barrier</para></listitem>
<listitem><para>initialisation of a pthread barrier on which threads
@@ -968,22 +977,34 @@
[default: full] ]]></option>
</term>
<listitem>
- <para>When set to <option>full</option> (the default), Helgrind
- collects enough information about "old" accesses that it can produce
- two stack traces in a race report -- both the stack trace for the
- current access, and the trace for the older, conflicting
- access.</para>
+ <para><option>--history-level=full</option> (the default) causes
+ Helgrind collects enough information about "old" accesses that
+ it can produce two stack traces in a race report -- both the
+ stack trace for the current access, and the trace for the
+ older, conflicting access.</para>
<para>Collecting such information is expensive in both speed and
- memory. However, without it, it is very much more difficult to
- track down the root causes of races. Nonetheless, you may not need
- it in situations where you just want to check for the presence or
- absence of races, for example, when doing regression testing of a
- previously race-free program.</para>
- <para>Setting this option to <option>approx</option> means that
- Helgrind will show a full trace for one thread, and an approximation
- for the other, and run faster. Setting it to <option>none</option>
- means that Helgrind will show a full trace for one thread, and
- nothing for the other, and run faster again.</para>
+ memory, particularly for programs that do many inter-thread
+ synchronisation events (locks, unlocks, etc). Without such
+ information, it is more difficult to track down the root
+ causes of races. Nonetheless, you may not need it in
+ situations where you just want to check for the presence or
+ absence of races, for example, when doing regression testing
+ of a previously race-free program.</para>
+ <para><option>--history-level=none</option> is the opposite
+ extreme. It causes Helgrind not to collect any information
+ about previous accesses. This can be dramatically faster
+ than <option>--history-level=full</option>.</para>
+ <para><option>--history-level=approx</option> provides a
+ compromise between these two extremes. It causes Helgrind to
+ show a full trace for the later access, and approximate
+ information regarding the earlier access. This approximate
+ information consists of two stacks, and the earlier access is
+ guaranteed to have occurred somewhere between program points
+ denoted by the two stacks. This is not as useful as showing
+ the exact stack for the previous access
+ (as <option>--history-level=full</option> does), but it is
+ better than nothing, and it is almost as fast as
+ <option>--history-level=none</option>.</para>
</listitem>
</varlistentry>
@@ -994,6 +1015,8 @@
[default: 1000000] ]]></option>
</term>
<listitem>
+ <para>This flag only has any effect
+ at <option>--history-level=full</option>.</para>
<para>Information about "old" conflicting accesses is stored in
a cache of limited size, with LRU-style management. This is
necessary because it isn't practical to store a stack trace
@@ -1005,10 +1028,10 @@
conflicting access information is stored. If you find that
Helgrind is showing race errors with only one stack instead of
the expected two stacks, try increasing this value.</para>
- <para>The minimum value is 10,000 and the maximum is 20,000,000
- (twenty times the default value). Increasing the value by 1
+ <para>The minimum value is 10,000 and the maximum is 30,000,000
+ (thirty times the default value). Increasing the value by 1
increases Helgrind's memory requirement by very roughly 100
- bytes, so the maximum value will easily eat up two extra
+ bytes, so the maximum value will easily eat up three extra
gigabytes or so of memory.</para>
</listitem>
</varlistentry>
@@ -1097,11 +1120,37 @@
<itemizedlist>
<listitem>
- <para><function>VALGRIND_HG_CLEAN_MEMORY</function>,
- This makes Helgrind forget everything it knows about a specified memory
- range. This is particularly useful for memory allocators that wish to
- recycle memory.</para>
+ <para><function>VALGRIND_HG_CLEAN_MEMORY</function></para>
+ <para>This makes Helgrind forget everything it knows about a
+ specified memory range. This is particularly useful for memory
+ allocators that wish to recycle memory.</para>
</listitem>
+ <listitem>
+ <para><function>ANNOTATE_HAPPENS_BEFORE</function></para>
+ </listitem>
+ <listitem>
+ <para><function>ANNOTATE_HAPPENS_AFTER</function></para>
+ </listitem>
+ <listitem>
+ <para><function>ANNOTATE_NEW_MEMORY</function></para>
+ </listitem>
+ <listitem>
+ <para><function>ANNOTATE_RWLOCK_CREATE</function></para>
+ </listitem>
+ <listitem>
+ <para><function>ANNOTATE_RWLOCK_DESTROY</function></para>
+ </listitem>
+ <listitem>
+ <para><function>ANNOTATE_RWLOCK_ACQUIRED</function></para>
+ </listitem>
+ <listitem>
+ <para><function>ANNOTATE_RWLOCK_RELEASED</function></para>
+ <para>These are used to describe to Helgrind, the behaviour of
+ custom (non-POSIX) synchronisation primitives, which it otherwise
+ has no way to understand. See comments
+ in <filename>helgrind.h</filename> for further
+ documentation.</para>
+ </listitem>
</itemizedlist>
@@ -1116,10 +1165,6 @@
some time.</para>
<itemizedlist>
- <listitem><para>Track which mutexes are associated with which
- condition variables, and emit a warning if this becomes
- inconsistent.</para>
- </listitem>
<listitem><para>For lock order errors, print the complete lock
cycle, rather than only doing for size-2 cycles as at
present.</para>
|
|
From: <sv...@va...> - 2009-08-16 22:50:12
|
Author: sewardj
Date: 2009-08-16 23:49:53 +0100 (Sun, 16 Aug 2009)
New Revision: 10830
Log:
Minor changes w.r.t. --read-var-info=, threading support, and
supported glibc versions.
Modified:
trunk/docs/xml/manual-core.xml
Modified: trunk/docs/xml/manual-core.xml
===================================================================
--- trunk/docs/xml/manual-core.xml 2009-08-16 22:47:02 UTC (rev 10829)
+++ trunk/docs/xml/manual-core.xml 2009-08-16 22:49:53 UTC (rev 10830)
@@ -1346,11 +1346,12 @@
<option><![CDATA[--read-var-info=<yes|no> [default: no] ]]></option>
</term>
<listitem>
- <para>When enabled, Valgrind will read information about variables from
- debug info. This slows Valgrind down and makes it use more memory, but
- for the tools that can take advantage of it (Memcheck, Helgrind, DRD) it
- can result in more precise error messages. For example, here are some
- standard errors issued by Memcheck:</para>
+ <para>When enabled, Valgrind will read information about
+ variable types and locations from DWARF3 debug info.
+ This slows Valgrind down and makes it use more memory, but for
+ the tools that can take advantage of it (Memcheck, Helgrind,
+ DRD) it can result in more precise error messages. For example,
+ here are some standard errors issued by Memcheck:</para>
<programlisting><![CDATA[
==15516== Uninitialised byte(s) found during client check request
==15516== at 0x400633: croak (varinfo1.c:28)
@@ -1555,23 +1556,29 @@
<sect1 id="manual-core.pthreads" xreflabel="Support for Threads">
<title>Support for Threads</title>
-<para>The main thing to point out with respect to multithreaded programs is
+<para>Threaded programs are fully supported.</para>
+
+<para>The main thing to point out with respect to threaded programs is
that your program will use the native threading library, but Valgrind
-serialises execution so that only one (kernel) thread is running at a time.
-This approach avoids the horrible implementation problems of implementing a
-truly multiprocessor version of Valgrind, but it does mean that threaded
-apps run only on one CPU, even if you have a multiprocessor machine.</para>
+serialises execution so that only one (kernel) thread is running at a
+time. This approach avoids the horrible implementation problems of
+implementing a truly multithreaded version of Valgrind, but it does
+mean that threaded apps run only on one CPU, even if you have a
+multiprocessor or multicore machine.</para>
-<para>Valgrind schedules your program's threads in a round-robin fashion,
-with all threads having equal priority. It switches threads
-every 100000 basic blocks (on x86, typically around 600000
-instructions), which means you'll get a much finer interleaving
-of thread executions than when run natively. This in itself may
-cause your program to behave differently if you have some kind of
-concurrency, critical race, locking, or similar, bugs. In that case
-you might consider using the tools Helgrind and/or DRD to track them
-down.</para>
+<para>Valgrind doesn't schedule the threads itself. It merely ensures
+that only one thread runs at once, using a simple locking scheme. The
+actual thread scheduling remains under control of the OS kernel. What
+this does mean, though, is that your program will see very different
+scheduling when run on Valgrind than it does when running normally.
+This is both because Valgrind is serialising the threads, and because
+the code runs so much slower than normal.</para>
+<para>This difference in scheduling may cause your program to behave
+differently, if you have some kind of concurrency, critical race,
+locking, or similar, bugs. In that case you might consider using the
+tools Helgrind and/or DRD to track them down.</para>
+
<para>On Linux, Valgrind also supports direct use of the
<computeroutput>clone</computeroutput> system call,
<computeroutput>futex</computeroutput> and so on.
@@ -1624,7 +1631,7 @@
<computeroutput>make</computeroutput>, <computeroutput>make
install</computeroutput> mechanism, and we have attempted to
ensure that it works on machines with kernel 2.4 or 2.6 and glibc
-2.2.X to 2.9.X. Once you have completed
+2.2.X to 2.10.X. Once you have completed
<computeroutput>make install</computeroutput> you may then want
to run the regression tests
with <computeroutput>make regtest</computeroutput>.
|
|
From: Nicholas N. <n.n...@gm...> - 2009-08-16 22:27:33
|
On Sun, Aug 16, 2009 at 10:49 PM, Rachel and Stuart<rac...@ra...> wrote: > For regular memory allocation we get to use |VALGRIND_DO_LEAK_CHECK. > There's no equivalent function for mempools. | It seems natural that if > there's an interface for tracking 'memory pools' with Valgrind, there > should be a way of reporting their leaks.|| VALGRIND_DO_LEAK_CHECK and --leak-check both look for leaks in all current memory pools. I don't know why you think this is not the case. memcheck/tests/mempool.c makes it clear -- for example, x1 and x2 are leaked. But, as you've been told, if you destroy a mempool all the chunks within it are freed, and so there can be no leaks from that mempool. That's why x3 and x4 aren't reported as leaked, because they've been freed. I think you should read the documentation again and try writing some small test programs to improve your understanding. NIck |
|
From: Stuart W. <de...@ra...> - 2009-08-16 21:13:03
|
Nicholas Nethercote wrote: > > I still don't understand. If a pool has been destroyed, all the > > blocks allocated from the pool have been freed. What leak checking is > > there to do? > > > The documentation says Valgrind mempool interface exists to support custom memory allocators (not just memory pools). It's just as valid to leak check allocations from custom allocators as it is from malloc and friends. For regular memory allocation we get to use VALGRIND_DO_LEAK_CHECK. There's no equivalent function for mempools. It seems natural that if there's an interface for tracking 'memory pools' with Valgrind, there should be a way of reporting their leaks. Anything that can be done for tracking malloc allocations should be able to be done with mempools. > > Yes. See http://www.valgrind.org/support/features.html. > > > > > Thanks for that. Reading it doesn't give me a lot of hope. I get the impression the mempool interface isn't widely used. The feature request is unlikely have any backers. Cheers, Stu Nicholas Nethercote wrote: > On Thu, Aug 13, 2009 at 10:20 PM, Stuart Warren<de...@ra...> wrote: > >> Thanks for that Nicholas. I agree with you that the test is working as >> documented but it's odd that the mempool code doesn't support leak >> checking for destroyed pools. It's not a lot of work to support this, >> it's more a matter of how. >> > > I still don't understand. If a pool has been destroyed, all the > blocks allocated from the pool have been freed. What leak checking is > there to do? > > >> I was going to raise a bug and attach the patch. Is that the best way >> for a casual contributor to get a change into Valgrind? >> > > Yes. See http://www.valgrind.org/support/features.html. > > Nick > > |
|
From: Ashley P. <as...@pi...> - 2009-08-16 15:51:06
|
On Thu, 2009-08-13 at 16:15 +0100, Ashley Pittman wrote: > > g) The "Command:" <line> in the xml preamble is superfluous. Attached is a patch to fix this issue. Ashley, -- Ashley Pittman, Bath, UK. Padb - A parallel job inspection tool for cluster computing http://padb.pittman.org.uk |
|
From: Ashley P. <as...@pi...> - 2009-08-16 11:30:34
|
On Sun, 2009-08-16 at 01:25 +0200, Julian Seward wrote:
> Ashley,
>
> I think you have some good points, esp w.r.t. the tagging when using
> --xml-socket. I see that the lack of it gets in your way.
>
> Can I suggest you open a bug report, to put this stuff on? We're trying
> to use bugzilla more actively, and it'll stop this all getting lost
> otherwise.
Ok, I'll open one.
> > Did you have any thoughts on the other points I mentioned, either
> > getting both sets of output and ideally a way of getting a qualifier in
> > over the --{log,file}-socket options.
>
> Could you show some examples of what you mean? (examples with simple
> bits of XML ?) I think I know what you're getting at, but am not sure.
I'll put something together. Even without using it to try and simplify
the testing it would be useful to be able to reproduce the non xml
output from the xml output.
In the mean time all that's needed from Valgrind is the ability to
output both xml and the standard output simultaneously.
Ashley.
--
Ashley Pittman, Bath, UK.
Padb - A parallel job inspection tool for cluster computing
http://padb.pittman.org.uk
|
|
From: Bart V. A. <bar...@gm...> - 2009-08-16 08:14:28
|
Nightly build on georgia-tech-cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) Started at 2009-08-16 02:15:56 EDT Ended at 2009-08-16 04:13:55 EDT Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 446 tests, 45 stderr failures, 9 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/wrap8 (stderr) none/tests/empty-exe (stderr) none/tests/linux/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/round (stdout) none/tests/shell (stdout) none/tests/shell (stderr) none/tests/shell_valid1 (stderr) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) none/tests/shell_zerolength (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/hsg (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 444 tests, 45 stderr failures, 9 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/wrap8 (stderr) none/tests/empty-exe (stderr) none/tests/linux/mremap (stderr) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/round (stdout) none/tests/shell (stdout) none/tests/shell (stderr) none/tests/shell_valid1 (stderr) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) none/tests/shell_zerolength (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/hsg (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Aug 16 03:14:41 2009 --- new.short Sun Aug 16 04:13:55 2009 *************** *** 8,10 **** ! == 444 tests, 45 stderr failures, 9 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) --- 8,10 ---- ! == 446 tests, 45 stderr failures, 9 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) |
|
From: Tom H. <th...@cy...> - 2009-08-16 02:49:35
|
Nightly build on vauxhall ( x86_64, Fedora 11 ) Started at 2009-08-16 03:20:07 BST Ended at 2009-08-16 03:49:08 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 539 tests, 8 stderr failures, 0 stdout failures, 0 post failures == memcheck/tests/linux/stack_switch (stderr) memcheck/tests/long_namespace_xml (stderr) helgrind/tests/pth_spinlock (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/qt4_rwlock (stderr) exp-ptrcheck/tests/bad_percentify (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 537 tests, 8 stderr failures, 0 stdout failures, 0 post failures == memcheck/tests/linux/stack_switch (stderr) memcheck/tests/long_namespace_xml (stderr) helgrind/tests/tc06_two_races_xml (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc23_bogus_condwait (stderr) drd/tests/qt4_rwlock (stderr) drd/tests/qt4_semaphore (stderr) exp-ptrcheck/tests/bad_percentify (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Aug 16 03:34:36 2009 --- new.short Sun Aug 16 03:49:08 2009 *************** *** 8,12 **** ! == 537 tests, 8 stderr failures, 0 stdout failures, 0 post failures == memcheck/tests/linux/stack_switch (stderr) memcheck/tests/long_namespace_xml (stderr) helgrind/tests/tc06_two_races_xml (stderr) --- 8,13 ---- ! == 539 tests, 8 stderr failures, 0 stdout failures, 0 post failures == memcheck/tests/linux/stack_switch (stderr) memcheck/tests/long_namespace_xml (stderr) + helgrind/tests/pth_spinlock (stderr) helgrind/tests/tc06_two_races_xml (stderr) *************** *** 15,17 **** drd/tests/qt4_rwlock (stderr) - drd/tests/qt4_semaphore (stderr) exp-ptrcheck/tests/bad_percentify (stderr) --- 16,17 ---- |
|
From: Tom H. <th...@cy...> - 2009-08-16 02:48:14
|
Nightly build on lloyd ( x86_64, Fedora 7 ) Started at 2009-08-16 03:05:03 BST Ended at 2009-08-16 03:47:54 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 529 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 527 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Aug 16 03:26:22 2009 --- new.short Sun Aug 16 03:47:54 2009 *************** *** 8,10 **** ! == 527 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) --- 8,10 ---- ! == 529 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: Tom H. <th...@cy...> - 2009-08-16 02:31:13
|
Nightly build on mg ( x86_64, Fedora 9 ) Started at 2009-08-16 03:10:06 BST Ended at 2009-08-16 03:30:53 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 536 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 534 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sun Aug 16 03:20:35 2009 --- new.short Sun Aug 16 03:30:53 2009 *************** *** 8,10 **** ! == 534 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) --- 8,10 ---- ! == 536 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: <sv...@va...> - 2009-08-16 01:58:14
|
Author: sewardj
Date: 2009-08-16 02:48:35 +0100 (Sun, 16 Aug 2009)
New Revision: 10828
Log:
ppc32-linux: di_notify_mmap: accept data sections mapped rwx as well as ones
mapped rw-. Fixes #190820. Really, this logic is still pretty ropey; we
could do a lot better here.
Modified:
trunk/coregrind/m_debuginfo/debuginfo.c
Modified: trunk/coregrind/m_debuginfo/debuginfo.c
===================================================================
--- trunk/coregrind/m_debuginfo/debuginfo.c 2009-08-16 00:20:58 UTC (rev 10827)
+++ trunk/coregrind/m_debuginfo/debuginfo.c 2009-08-16 01:48:35 UTC (rev 10828)
@@ -699,13 +699,16 @@
x86-linux: consider if r and x
all others: consider if r and x and not w
+
+ 2009 Aug 16: apply similar kludge to ppc32-linux.
+ See http://bugs.kde.org/show_bug.cgi?id=190820
*/
is_rx_map = False;
is_rw_map = False;
-# if defined(VGA_x86)
+# if defined(VGA_x86) || defined(VGA_ppc32)
is_rx_map = seg->hasR && seg->hasX;
is_rw_map = seg->hasR && seg->hasW;
-# elif defined(VGA_amd64) || defined(VGA_ppc32) || defined(VGA_ppc64)
+# elif defined(VGA_amd64) || defined(VGA_ppc64)
is_rx_map = seg->hasR && seg->hasX && !seg->hasW;
is_rw_map = seg->hasR && seg->hasW && !seg->hasX;
# else
|
|
From: <sv...@va...> - 2009-08-16 00:21:48
|
Author: njn Date: 2009-08-16 01:20:58 +0100 (Sun, 16 Aug 2009) New Revision: 10827 Log: tweak 32/64-bit darwin stuff Modified: trunk/NEWS Modified: trunk/NEWS =================================================================== --- trunk/NEWS 2009-08-16 00:00:17 UTC (rev 10826) +++ trunk/NEWS 2009-08-16 00:20:58 UTC (rev 10827) @@ -15,7 +15,7 @@ Here is a short summary of the changes. Details are shown further down: -* Support for Mac OS X 10.5.x. +* Support for Mac OS X (10.5.x). * Improvements and simplifications to Memcheck's leak checker. @@ -41,21 +41,24 @@ * Valgrind now runs on Mac OS X. (Note that Mac OS X is sometimes - called "Darwin" because that is the name of the OS core.) + called "Darwin" because that is the name of the OS core, which is the + level that Valgrind works at.) - Supported machines: + Supported systems: - - x86 machines are supported fairly well. + - It requires OS 10.5.x (Leopard). Porting to 10.4.x is not planned + because it would require work and 10.4 is only becoming less common. - - amd64 (a.k.a. x86-64) are supported, but not as well. In - particular, start-up is slow. + - 32-bit programs on x86 and AMD64 (a.k.a x86-64) machines are supported + fairly well. For 10.5.x, 32-bit programs are the default even on + 64-bit machines, so it handles most current programs. + + - 64-bit programs on x86 and AMD64 (a.k.a x86-64) machines are not + officially supported, but simple programs at least will probably work. + However, start-up is slow. - PowerPC machines are not supported. - - It requires Mac OS X 10.5 Leopard or later. Porting to 10.4 is not - planned because it would require work and 10.4 is only becoming less - common. - Things that don't work: - The Ptrcheck tool. |
|
From: <sv...@va...> - 2009-08-16 00:00:32
|
Author: njn
Date: 2009-08-16 01:00:17 +0100 (Sun, 16 Aug 2009)
New Revision: 10826
Log:
Fix the access_extended wrapper, which was rather broken. That's what I get
for not testing properly. Added a regtest for it too. Fixes bug 200760
(again, properly this time).
Added:
trunk/none/tests/darwin/access_extended.c
trunk/none/tests/darwin/access_extended.stderr.exp
trunk/none/tests/darwin/access_extended.vgtest
Modified:
trunk/coregrind/m_syswrap/syswrap-darwin.c
trunk/none/tests/darwin/Makefile.am
Modified: trunk/coregrind/m_syswrap/syswrap-darwin.c
===================================================================
--- trunk/coregrind/m_syswrap/syswrap-darwin.c 2009-08-15 23:33:04 UTC (rev 10825)
+++ trunk/coregrind/m_syswrap/syswrap-darwin.c 2009-08-16 00:00:17 UTC (rev 10826)
@@ -2069,6 +2069,9 @@
{
PRINT("access_extended( %#lx(%s), %lu, %#lx, %lu )",
ARG1, (char *)ARG1, ARG2, ARG3, ARG4);
+ // XXX: the accessx_descriptor struct contains padding, so this can cause
+ // unnecessary undefined value errors. But you arguably shouldn't be
+ // passing undefined values to the kernel anyway...
PRE_REG_READ4(int, "access_extended", void *, entries, vki_size_t, size,
vki_errno_t *, results, vki_uid_t *, uid);
PRE_MEM_READ("access_extended(entries)", ARG1, ARG2 );
@@ -2084,18 +2087,17 @@
// shortest possible string section. The shortest string section allowed
// consists of a single one-char string (plus the NUL char). Hence the
// '2'.
- struct vki_accessx_descriptor* entries = (struct vki_accessx_descriptor*)ARG2;
+ struct vki_accessx_descriptor* entries = (struct vki_accessx_descriptor*)ARG1;
SizeT size = ARG2;
Int n_descs = (size - 2) / sizeof(struct accessx_descriptor);
- Int i = 0; // Current position in the descriptors section array.
+ Int i; // Current position in the descriptors section array.
Int u; // Upper bound on the length of the descriptors array
- // (recomputed each time around the loop)
+ // (recomputed each time around the loop)
vg_assert(n_descs > 0);
// Step through the descriptors, lowering 'n_descs' until we know we've
// reached the string section.
- while (True)
- {
+ for (i = 0; True; i++) {
// If we're past our estimate, we must be one past the end of the
// descriptors section (ie. at the start of the string section). Stop.
if (i >= n_descs)
Modified: trunk/none/tests/darwin/Makefile.am
===================================================================
--- trunk/none/tests/darwin/Makefile.am 2009-08-15 23:33:04 UTC (rev 10825)
+++ trunk/none/tests/darwin/Makefile.am 2009-08-16 00:00:17 UTC (rev 10826)
@@ -4,10 +4,12 @@
dist_noinst_SCRIPTS = filter_stderr
EXTRA_DIST = \
+ access_extended.stderr.exp access_extended.vgtest \
apple-main-arg.stderr.exp apple-main-arg.vgtest \
rlimit.stderr.exp rlimit.vgtest
check_PROGRAMS = \
+ access_extended \
apple-main-arg \
rlimit
Added: trunk/none/tests/darwin/access_extended.c
===================================================================
--- trunk/none/tests/darwin/access_extended.c (rev 0)
+++ trunk/none/tests/darwin/access_extended.c 2009-08-16 00:00:17 UTC (rev 10826)
@@ -0,0 +1,48 @@
+// This is a test for access_extended(), one of the more ridiculous syscalls
+// ever devised. For bug 200760. See the comments on the wrapper in
+// syswrap-darwin.c to understand what is going on here.
+
+#include <sys/syscall.h>
+#include <unistd.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+
+int main(void)
+{
+ char* name1 = "access_extended.c";
+ char* name2 = "no_such_file";
+ // Space for three descriptors and the two strings (and NUL chars for them).
+ size_t entries_szB =
+ sizeof(struct accessx_descriptor) * 3 +
+ strlen(name1) + 1 +
+ strlen(name2) + 1;
+ struct accessx_descriptor* entries = malloc(entries_szB);
+ char* string1 = (char*)&entries[3];
+ char* string2 = string1 + strlen(name1) + 1;
+ int results[3];
+ int retval;
+
+ entries[0].ad_name_offset = string1 - (char*)entries;
+ entries[1].ad_name_offset = 0; // reuse the previous entry's string
+ entries[2].ad_name_offset = string2 - (char*)entries;
+ entries[0].ad_flags = F_OK; // succeeds
+ entries[1].ad_flags = X_OK; // fails
+ entries[2].ad_flags = F_OK; // fails
+ strcpy(string1, name1);
+ strcpy(string2, name2);
+
+ retval = syscall(SYS_access_extended, entries, entries_szB, results,
+ /*uid--unused?*/0);
+
+ fprintf(stderr, "retval = %d\n", retval);
+ fprintf(stderr, "%s(F_OK) = %d (%s)\n",
+ name1, results[0], strerror(results[0]));
+ fprintf(stderr, "%s(X_OK) = %d (%s)\n",
+ name1, results[1], strerror(results[1]));
+ fprintf(stderr, "%s(F_OK) = %d (%s)\n",
+ name2, results[2], strerror(results[2]));
+
+ return 0;
+}
+
Added: trunk/none/tests/darwin/access_extended.stderr.exp
===================================================================
--- trunk/none/tests/darwin/access_extended.stderr.exp (rev 0)
+++ trunk/none/tests/darwin/access_extended.stderr.exp 2009-08-16 00:00:17 UTC (rev 10826)
@@ -0,0 +1,4 @@
+retval = 0
+access_extended.c(F_OK) = 0 (Unknown error: 0)
+access_extended.c(X_OK) = 13 (Permission denied)
+no_such_file(F_OK) = 2 (No such file or directory)
Added: trunk/none/tests/darwin/access_extended.vgtest
===================================================================
--- trunk/none/tests/darwin/access_extended.vgtest (rev 0)
+++ trunk/none/tests/darwin/access_extended.vgtest 2009-08-16 00:00:17 UTC (rev 10826)
@@ -0,0 +1,2 @@
+prog: access_extended
+vgopts: -q
|