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
(1) |
2
(4) |
3
(3) |
4
(6) |
5
(14) |
6
(10) |
7
(4) |
|
8
(2) |
9
(4) |
10
(7) |
11
(8) |
12
(5) |
13
(11) |
14
(4) |
|
15
(4) |
16
(9) |
17
(6) |
18
|
19
|
20
|
21
|
|
22
(3) |
23
(1) |
24
(7) |
25
(12) |
26
(8) |
27
(13) |
28
(4) |
|
29
(3) |
30
(4) |
|
|
|
|
|
|
From: Konstantin S. <kon...@gm...> - 2009-11-06 07:09:23
|
I don't see any difference between this test and mine.
Pure happens-before detectors are silent, hybrid detectors report a (false)
race.
/usr/bin/gcc -Wall -Wextra -ansi -pedantic -o waittest -g3 waittest.c -l
pthread
% (sleep 1; echo) | ~/valgrind/trunk/inst/bin/valgrind --tool=drd -q
./waittest
1
% (sleep 1; echo) | ~/valgrind/trunk/inst/bin/valgrind --tool=helgrind -q
./waittest
1
% (sleep 1; echo) | tsan -q ./waittest
==22239== ThreadSanitizerValgrind: pure-happens-before=no fast-mode=yes
ignore-in-dtor=yes
1
% (sleep 1; echo) | tsan -q --fast-mode=no ./waittest
==22719== ThreadSanitizerValgrind: pure-happens-before=no fast-mode=no
ignore-in-dtor=yes
==22719== WARNING: Possible data race during read of size 4 at 0x601300: {{{
==22719== T0 (locks held: {}):
==22719== #0 main /tmp/waittest.c:79
==22719== Concurrent write(s) happened at (OR AFTER) these points:
==22719== T1 (locks held: {}):
==22719== #0 produce /tmp/waittest.c:17
==22719== #1 ThreadSanitizerStartThread ts_valgrind_intercepts.c:504
==22719== Address 0x601300 is 0 bytes inside data symbol
"msg_to_publish.2907"
==22719== }}}
==22719==
1
--kcc
On Fri, Nov 6, 2009 at 1:38 AM, ERSEK Laszlo <la...@ca...> wrote:
> On Thu, 5 Nov 2009, Bart Van Assche wrote:
>
> > Can you please post a small self-standing program or comment on
> > Konstantin's test program
> > (
> http://code.google.com/p/data-race-test/source/browse/trunk/unittest/racecheck_unittest.cc#520
> )
> > ? I prefer commenting on a program that can be compiled and run instead
> > of commenting on incomplete program fragments.
>
> Konstantin didn't get the false positives described in the manual. What I
> proposed is only for the case when there's a false positive to avert, so
> if there's no false positive then my proposition is automatically void.
>
> I installed valgrind-3.5.0 from source and wrote a small program:
>
> http://pastebin.com/f6a4181c2
>
> (You'll have to hit enter after a second or so when running it.)
>
> I didn't get any false positives either.
>
> Cheers,
> lacos
>
>
> ------------------------------------------------------------------------------
> 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: Tom H. <th...@cy...> - 2009-11-06 03:50:13
|
Nightly build on vauxhall ( x86_64, Fedora 11 ) Started at 2009-11-06 03:20:05 GMT Ended at 2009-11-06 03:49:45 GMT 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 == 541 tests, 7 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) 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 == 541 tests, 7 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_semaphore (stderr) exp-ptrcheck/tests/bad_percentify (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Fri Nov 6 03:35:02 2009 --- new.short Fri Nov 6 03:49:45 2009 *************** *** 14,16 **** helgrind/tests/tc23_bogus_condwait (stderr) ! drd/tests/qt4_semaphore (stderr) exp-ptrcheck/tests/bad_percentify (stderr) --- 14,16 ---- helgrind/tests/tc23_bogus_condwait (stderr) ! drd/tests/qt4_rwlock (stderr) exp-ptrcheck/tests/bad_percentify (stderr) |
|
From: Tom H. <th...@cy...> - 2009-11-06 03:48:50
|
Nightly build on lloyd ( x86_64, Fedora 7 ) Started at 2009-11-06 03:05:05 GMT Ended at 2009-11-06 03:48:33 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 531 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: Tom H. <th...@cy...> - 2009-11-06 03:35:29
|
Nightly build on mg ( x86_64, Fedora 9 ) Started at 2009-11-06 03:10:07 GMT Ended at 2009-11-06 03:35:10 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 538 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: ERSEK L. <la...@ca...> - 2009-11-05 22:38:45
|
On Thu, 5 Nov 2009, Bart Van Assche wrote: > Can you please post a small self-standing program or comment on > Konstantin's test program > (http://code.google.com/p/data-race-test/source/browse/trunk/unittest/racecheck_unittest.cc#520) > ? I prefer commenting on a program that can be compiled and run instead > of commenting on incomplete program fragments. Konstantin didn't get the false positives described in the manual. What I proposed is only for the case when there's a false positive to avert, so if there's no false positive then my proposition is automatically void. I installed valgrind-3.5.0 from source and wrote a small program: http://pastebin.com/f6a4181c2 (You'll have to hit enter after a second or so when running it.) I didn't get any false positives either. Cheers, lacos |
|
From: Bart V. A. <bar...@gm...> - 2009-11-05 20:13:39
|
On Thu, Nov 5, 2009 at 8:48 PM, ERSEK Laszlo <la...@ca...> wrote: > > Does your solution help? > > I didn't try it out. If we cannot prove it's correct (or worse, we can > disprove it), there's no need to. If we prove it correct, there's kinda no > need to either :) Hello Laszlo, Can you please post a small self-standing program or comment on Konstantin's test program (http://code.google.com/p/data-race-test/source/browse/trunk/unittest/racecheck_unittest.cc#520) ? I prefer commenting on a program that can be compiled and run instead of commenting on incomplete program fragments. Bart. |
|
From: ERSEK L. <la...@ca...> - 2009-11-05 19:48:24
|
(Is SF broken? The web interface doesn't thread threads; whitespace formatting is lost even though my message was plain text; I didn't receive Julian's reply, even though I'm subscribed and receive commit logs and other messages; and only two thirds of the calendar table fit into a browser window 954 pixels wide.) On Thu, Nov 5, 2009 at 11:15 AM, Julian Seward <js...@ac...> wrote: > I believe Laszlo's comments are valid and correct, and an interesting > solution. I'd have to stare at it more it be convinced it's correct, but > it looks plausible. Thank you. I figured it might not be completely useless if somebody can compile her code with all these holding: - the code stays correct, - Valgrind headers are not installed -- no Valgrind specific ANNOTATE_* macros, - Valgrind still sees the condvar dependency in the binary in any case. (I think of this as a possible manual amendment, not a change to valgrind's instrumentation. I have no idea whether that would be possible at all.) > Laszlo, can you explain the background to this a bit? How did you come > to be looking at this problem? I develop lbzip2 (see <200...@ac...>), and the sponsor of my lbzip2 Debian package, Paul Wise, mentioned valgrind. I said I already tested with valgrind [0]. (Not because I was investigating a bug -- I was simply curious.) However, this made me remember reading some caveat in the Helgrind manual. I re-read that section and pthread_cond_timedwait() just occurred to me. > Does your solution help? I didn't try it out. If we cannot prove it's correct (or worse, we can disprove it), there's no need to. If we prove it correct, there's kinda no need to either :) Thanks, lacos [0] http://lists.debian.org/debian-mentors/2009/11/msg00060.html |
|
From: Ashley P. <as...@pi...> - 2009-11-05 18:44:56
|
On Thu, 2009-11-05 at 09:22 +0000, sv...@va... wrote: > Modified: > branches/ARM/ I've got an ARM machine running 24x7 if you need it for regression testing. /proc/cpuinfo is: Processor : XScale-IXP42x Family rev 1 (v5l) BogoMIPS : 266.24 Features : swp half fastmult edsp CPU implementer : 0x69 CPU architecture: 5TE CPU variant : 0x0 CPU part : 0x41f CPU revision : 1 Cache type : undefined 5 Cache clean : undefined 5 Cache lockdown : undefined 5 Cache format : Harvard I size : 32768 I assoc : 32 I line length : 32 I sets : 32 D size : 32768 D assoc : 32 D line length : 32 D sets : 32 Hardware : Linksys NSLU2 Revision : 0000 Serial : 0000000000000000 Ashley, -- Ashley Pittman, Bath, UK. Padb - A parallel job inspection tool for cluster computing http://padb.pittman.org.uk |
|
From: <sv...@va...> - 2009-11-05 18:22:56
|
Author: sewardj Date: 2009-11-05 18:22:34 +0000 (Thu, 05 Nov 2009) New Revision: 1926 Log: Initial support for ARM: core integer insn set (v5), a couple of v6 instructions, and fairly complete VFPv1 support. Modified: branches/ARM/Makefile-gcc branches/ARM/auxprogs/genoffsets.c branches/ARM/priv/guest_amd64_toIR.c branches/ARM/priv/guest_arm_defs.h branches/ARM/priv/guest_arm_helpers.c branches/ARM/priv/guest_arm_toIR.c branches/ARM/priv/guest_ppc_toIR.c branches/ARM/priv/guest_x86_toIR.c branches/ARM/priv/host_amd64_isel.c branches/ARM/priv/host_arm_defs.c branches/ARM/priv/host_arm_defs.h branches/ARM/priv/host_arm_isel.c branches/ARM/priv/host_generic_reg_alloc2.c branches/ARM/priv/host_generic_regs.c branches/ARM/priv/host_generic_regs.h branches/ARM/priv/host_ppc_isel.c branches/ARM/priv/host_x86_isel.c branches/ARM/priv/ir_defs.c branches/ARM/priv/ir_opt.c branches/ARM/priv/main_main.c branches/ARM/pub/libvex_basictypes.h branches/ARM/pub/libvex_guest_arm.h branches/ARM/pub/libvex_ir.h [... diff too large to include ...] |
|
From: <sv...@va...> - 2009-11-05 18:21:37
|
Author: sewardj Date: 2009-11-05 18:21:28 +0000 (Thu, 05 Nov 2009) New Revision: 10930 Log: Initial port to arm-linux. This is an updated and modified version of the port done by Evan Geller and Johan Bj?\195?\182rk. Added: branches/ARM/cachegrind/cg-arm.c branches/ARM/coregrind/m_dispatch/dispatch-arm-linux.S branches/ARM/coregrind/m_sigframe/sigframe-arm-linux.c branches/ARM/coregrind/m_syswrap/syscall-arm-linux.S branches/ARM/coregrind/m_syswrap/syswrap-arm-linux.c branches/ARM/include/vki/vki-arm-linux.h branches/ARM/include/vki/vki-posixtypes-arm-linux.h branches/ARM/include/vki/vki-scnums-arm-linux.h branches/ARM/none/tests/arm/ branches/ARM/none/tests/arm/Makefile.am Modified: branches/ARM/Makefile.all.am branches/ARM/Makefile.am branches/ARM/Makefile.tool.am branches/ARM/Makefile.vex.am branches/ARM/auxprogs/gsl16test branches/ARM/cachegrind/Makefile.am branches/ARM/cachegrind/cg_branchpred.c branches/ARM/configure.in branches/ARM/coregrind/Makefile.am branches/ARM/coregrind/launcher-linux.c branches/ARM/coregrind/m_aspacemgr/aspacemgr-common.c branches/ARM/coregrind/m_aspacemgr/aspacemgr-linux.c branches/ARM/coregrind/m_coredump/coredump-elf.c branches/ARM/coregrind/m_cpuid.S branches/ARM/coregrind/m_debugger.c branches/ARM/coregrind/m_debuginfo/d3basics.c branches/ARM/coregrind/m_debuginfo/debuginfo.c branches/ARM/coregrind/m_debuginfo/readdwarf.c branches/ARM/coregrind/m_debuginfo/readelf.c branches/ARM/coregrind/m_debuglog.c branches/ARM/coregrind/m_initimg/initimg-linux.c branches/ARM/coregrind/m_libcassert.c branches/ARM/coregrind/m_libcfile.c branches/ARM/coregrind/m_libcproc.c branches/ARM/coregrind/m_machine.c branches/ARM/coregrind/m_main.c branches/ARM/coregrind/m_redir.c branches/ARM/coregrind/m_scheduler/scheduler.c branches/ARM/coregrind/m_signals.c branches/ARM/coregrind/m_stacktrace.c branches/ARM/coregrind/m_syscall.c branches/ARM/coregrind/m_syswrap/priv_types_n_macros.h branches/ARM/coregrind/m_syswrap/syswrap-linux.c branches/ARM/coregrind/m_syswrap/syswrap-main.c branches/ARM/coregrind/m_trampoline.S branches/ARM/coregrind/m_translate.c branches/ARM/coregrind/m_transtab.c branches/ARM/coregrind/pub_core_basics.h branches/ARM/coregrind/pub_core_machine.h branches/ARM/coregrind/pub_core_mallocfree.h branches/ARM/coregrind/pub_core_syscall.h branches/ARM/coregrind/pub_core_threadstate.h branches/ARM/coregrind/pub_core_trampoline.h branches/ARM/coregrind/pub_core_transtab_asm.h branches/ARM/docs/internals/register-uses.txt branches/ARM/include/pub_tool_basics.h branches/ARM/include/pub_tool_machine.h branches/ARM/include/pub_tool_vkiscnums_asm.h branches/ARM/include/valgrind.h branches/ARM/include/vki/vki-linux.h branches/ARM/memcheck/mc_machine.c branches/ARM/memcheck/mc_translate.c [... diff too large to include ...] |
|
From: Konstantin S. <kon...@gm...> - 2009-11-05 15:38:45
|
On Thu, Nov 5, 2009 at 11:15 AM, Julian Seward <js...@ac...> wrote: > On Thursday 05 November 2009, Konstantin Serebryany wrote: > > > I think this section of helgrind docs is generally out of date (Julian, > > please confirm). > > Helgrind 3.5 is a pure happens-before detector and thus handles this case > > correctly. > > Same for DRD. > > Unfortunately I think the docs are correct, and neither Helgrind nor DRD > can handle this properly. Hm. Why??? cond var should only be used between mutex lock/unlock and those create h-b arcs... Here is the test: http://code.google.com/p/data-race-test/source/browse/trunk/unittest/racecheck_unittest.cc#520 Helgrind, DRD and ThreadSanitizer (in pure happens-before mode) are silent here. ThreadSanitizer in the hybrid mode barks. void Waker() { GLOB = 1; MU.Lock(); COND = 1; CV.Signal(); MU.Unlock(); } void Waiter() { usleep(100000); // Make sure the signaller gets first. MU.Lock(); while(COND != 1) CV.Wait(&MU); MU.Unlock(); GLOB = 2; } > The basic problem is that there can be a h-b > dependency which arises from the loop and values in memory, not from the > mx or cv, so the dependency is "invisible". > > I believe Laszlo's comments are valid and correct, and an interesting > solution. I'd have to stare at it more it be convinced it's correct, > but it looks plausible. > > Laszlo, can you explain the background to this a bit? How did you > come to be looking at this problem? Does your solution help? > > J > |
|
From: <sv...@va...> - 2009-11-05 09:22:19
|
Author: sewardj Date: 2009-11-05 09:22:06 +0000 (Thu, 05 Nov 2009) New Revision: 10929 Log: Swizzle external. Modified: branches/ARM/ Property changes on: branches/ARM ___________________________________________________________________ Name: svn:externals - VEX svn://svn.valgrind.org/vex/trunk + VEX svn://svn.valgrind.org/vex/branches/ARM |
|
From: <sv...@va...> - 2009-11-05 09:21:08
|
Author: sewardj Date: 2009-11-05 09:20:54 +0000 (Thu, 05 Nov 2009) New Revision: 10928 Log: Make a copy of trunk r10927, for ARM-Linux. Added: branches/ARM/ Copied: branches/ARM (from rev 10927, trunk) |
|
From: <sv...@va...> - 2009-11-05 09:18:36
|
Author: sewardj Date: 2009-11-05 09:18:22 +0000 (Thu, 05 Nov 2009) New Revision: 1925 Log: Make a copy of trunk r1924 for ARM. Added: branches/ARM/ Copied: branches/ARM (from rev 1924, trunk) |
|
From: <sv...@va...> - 2009-11-05 08:55:26
|
Author: sewardj
Date: 2009-11-05 08:55:13 +0000 (Thu, 05 Nov 2009)
New Revision: 10927
Log:
New flag: --trace-children-skip=patt1,patt2,etc
Specifies a comma-separated list of executable-names
(with "*" and "?" wildcards allowed) that should not be traced into
even when --trace-children=yes. Modified version of a patch
from Bill Hoffman. Fixes #148932.
Modified:
trunk/coregrind/m_main.c
trunk/coregrind/m_options.c
trunk/coregrind/m_syswrap/syswrap-aix5.c
trunk/coregrind/m_syswrap/syswrap-darwin.c
trunk/coregrind/m_syswrap/syswrap-generic.c
trunk/coregrind/pub_core_options.h
trunk/docs/xml/manual-core.xml
trunk/none/tests/cmdline1.stdout.exp
trunk/none/tests/cmdline2.stdout.exp
Modified: trunk/coregrind/m_main.c
===================================================================
--- trunk/coregrind/m_main.c 2009-11-05 08:43:38 UTC (rev 10926)
+++ trunk/coregrind/m_main.c 2009-11-05 08:55:13 UTC (rev 10927)
@@ -121,6 +121,8 @@
" -q --quiet run silently; only print error msgs\n"
" -v --verbose be more verbose -- show misc extra info\n"
" --trace-children=no|yes Valgrind-ise child processes (follow execve)? [no]\n"
+" --trace-children-skip=patt1,patt2,... specifies a list of executables\n"
+" that --trace-children=yes should not trace into\n"
" --child-silent-after-fork=no|yes omit child output between fork & exec? [no]\n"
" --track-fds=no|yes track open file descriptors? [no]\n"
" --time-stamp=no|yes add timestamps to log messages? [no]\n"
@@ -490,6 +492,8 @@
else if VG_BOOL_CLO(arg, "--dsymutil", VG_(clo_dsymutil)) {}
+ else if VG_STR_CLO (arg, "--trace-children-skip", VG_(clo_trace_children_skip)) {}
+
else if VG_BINT_CLO(arg, "--vex-iropt-verbosity",
VG_(clo_vex_control).iropt_verbosity, 0, 10) {}
else if VG_BINT_CLO(arg, "--vex-iropt-level",
Modified: trunk/coregrind/m_options.c
===================================================================
--- trunk/coregrind/m_options.c 2009-11-05 08:43:38 UTC (rev 10926)
+++ trunk/coregrind/m_options.c 2009-11-05 08:55:13 UTC (rev 10927)
@@ -38,6 +38,7 @@
#include "pub_core_libcprint.h"
#include "pub_core_libcproc.h"
#include "pub_core_mallocfree.h"
+#include "pub_core_seqmatch.h" // VG_(string_match)
// See pub_{core,tool}_options.h for explanations of all these.
@@ -56,6 +57,7 @@
HChar* VG_(clo_xml_user_comment) = NULL;
Bool VG_(clo_demangle) = True;
Bool VG_(clo_trace_children) = False;
+HChar* VG_(clo_trace_children_skip) = NULL;
Bool VG_(clo_child_silent_after_fork) = False;
Char* VG_(clo_log_fname_expanded) = NULL;
Char* VG_(clo_xml_fname_expanded) = NULL;
@@ -264,8 +266,71 @@
}
}
+/*====================================================================*/
+/*=== --trace-children= support ===*/
+/*====================================================================*/
+static HChar const* consume_commas ( HChar const* c ) {
+ while (*c && *c == ',') {
+ ++c;
+ }
+ return c;
+}
+static HChar const* consume_field ( HChar const* c ) {
+ while (*c && *c != ',') {
+ ++c;
+ }
+ return c;
+}
+
+/* Should we trace into this child executable (across execve etc) ?
+ This involves considering --trace-children=, --trace-children-skip=
+ and the name of the executable. */
+Bool VG_(should_we_trace_this_child) ( HChar* child_exe_name )
+{
+ // child_exe_name is pulled out of the guest's space. We
+ // should be at least marginally cautious with it, lest it
+ // explode or burst into flames unexpectedly.
+ if (child_exe_name == NULL || VG_(strlen)(child_exe_name) == 0)
+ return VG_(clo_trace_children); // we know narfink
+
+ // the main logic
+ // If --trace-children=no, the answer is simply NO.
+ if (! VG_(clo_trace_children))
+ return False;
+
+ // otherwise, return True, unless the exe name matches any of the
+ // patterns specified by --trace-children-skip=.
+ if (VG_(clo_trace_children_skip)) {
+ HChar const* last = VG_(clo_trace_children_skip);
+ HChar const* name = (HChar const*)child_exe_name;
+ while (*last) {
+ Bool matches;
+ HChar* patt;
+ HChar const* first = consume_commas(last);
+ last = consume_field(first);
+ if (first == last)
+ break;
+ vg_assert(last > first);
+ /* copy the candidate string into a temporary malloc'd block
+ so we can use VG_(string_match) on it. */
+ patt = VG_(calloc)("m_options.swttc.1", last - first + 1, 1);
+ VG_(memcpy)(patt, first, last - first);
+ vg_assert(patt[last-first] == 0);
+ matches = VG_(string_match)(patt, name);
+ VG_(free)(patt);
+ if (matches)
+ return False;
+ }
+ }
+
+ // --trace-children=yes, and this particular executable isn't
+ // excluded
+ return True;
+}
+
+
/*--------------------------------------------------------------------*/
/*--- end m_options.c ---*/
/*--------------------------------------------------------------------*/
Modified: trunk/coregrind/m_syswrap/syswrap-aix5.c
===================================================================
--- trunk/coregrind/m_syswrap/syswrap-aix5.c 2009-11-05 08:43:38 UTC (rev 10926)
+++ trunk/coregrind/m_syswrap/syswrap-aix5.c 2009-11-05 08:55:13 UTC (rev 10927)
@@ -798,7 +798,8 @@
a += sizeof(char*);
}
}
-static SysRes simple_pre_exec_check(const HChar* exe_name)
+static SysRes simple_pre_exec_check ( const HChar* exe_name,
+ Bool trace_this_child )
{
Int fd, ret;
SysRes res;
@@ -815,7 +816,7 @@
// Check we have execute permissions. We allow setuid executables
// to be run only in the case when we are not simulating them, that
// is, they to be run natively.
- setuid_allowed = VG_(clo_trace_children) ? False : True;
+ setuid_allowed = trace_this_child ? False : True;
ret = VG_(check_executable)(NULL/*&is_setuid*/,
(HChar*)exe_name, setuid_allowed);
if (0 != ret) {
@@ -833,6 +834,7 @@
ThreadState* tst;
Int i, j, tot_args;
SysRes res;
+ Bool trace_this_child;
PRINT("sys_execve ( %#lx(%s), %#lx, %#lx )", ARG1, (Char*)ARG1, ARG2, ARG3);
PRE_REG_READ3(vki_off_t, "execve",
@@ -862,10 +864,16 @@
// SET_STATUS_Failure( VKI_EFAULT );
// return;
//}
+ if (ARG1 == 0 /* obviously bogus */) {
+ SET_STATUS_Failure( VKI_EFAULT );
+ }
+ // Decide whether or not we want to follow along
+ trace_this_child = VG_(should_we_trace_this_child)( (HChar*)ARG1 );
+
// Do the important checks: it is a file, is executable, permissions are
// ok, etc.
- res = simple_pre_exec_check((const HChar*)ARG1);
+ res = simple_pre_exec_check( (const HChar*)ARG1, trace_this_child );
if (res.isError) {
SET_STATUS_Failure( res.err );
return;
@@ -874,7 +882,7 @@
/* If we're tracing the child, and the launcher name looks bogus
(possibly because launcher.c couldn't figure it out, see
comments therein) then we have no option but to fail. */
- if (VG_(clo_trace_children)
+ if (trace_this_child
&& (VG_(name_of_launcher) == NULL
|| VG_(name_of_launcher)[0] != '/')) {
SET_STATUS_Failure( VKI_ECHILD ); /* "No child processes" */
@@ -892,7 +900,7 @@
// Set up the child's exe path.
//
- if (VG_(clo_trace_children)) {
+ if (trace_this_child) {
// We want to exec the launcher. Get its pre-remembered path.
path = VG_(name_of_launcher);
@@ -930,7 +938,7 @@
VG_(env_remove_valgrind_env_stuff)( envp );
}
- if (VG_(clo_trace_children)) {
+ if (trace_this_child) {
// Set VALGRIND_LIB in ARG3 (the environment)
VG_(env_setenv)( &envp, VALGRIND_LIB, VG_(libdir));
}
@@ -943,7 +951,7 @@
// except that the first VG_(args_for_valgrind_noexecpass) args
// are omitted.
//
- if (!VG_(clo_trace_children)) {
+ if (!trace_this_child) {
argv = (Char**)ARG2;
} else {
vg_assert( VG_(args_for_valgrind_noexecpass) >= 0 );
Modified: trunk/coregrind/m_syswrap/syswrap-darwin.c
===================================================================
--- trunk/coregrind/m_syswrap/syswrap-darwin.c 2009-11-05 08:43:38 UTC (rev 10926)
+++ trunk/coregrind/m_syswrap/syswrap-darwin.c 2009-11-05 08:55:13 UTC (rev 10927)
@@ -2556,7 +2556,8 @@
a += sizeof(char*);
}
}
-static SysRes simple_pre_exec_check(const HChar* exe_name)
+static SysRes simple_pre_exec_check ( const HChar* exe_name,
+ Bool trace_this_child )
{
Int fd, ret;
SysRes res;
@@ -2573,7 +2574,7 @@
// Check we have execute permissions. We allow setuid executables
// to be run only in the case when we are not simulating them, that
// is, they to be run natively.
- setuid_allowed = VG_(clo_trace_children) ? False : True;
+ setuid_allowed = trace_this_child ? False : True;
ret = VG_(check_executable)(NULL/*&is_setuid*/,
(HChar*)exe_name, setuid_allowed);
if (0 != ret) {
@@ -2590,6 +2591,7 @@
Char* launcher_basename = NULL;
Int i, j, tot_args;
SysRes res;
+ Bool trace_this_child;
/* args: pid_t* pid
char* path
@@ -2622,15 +2624,19 @@
syswrap-generic.c. */
/* Check that the name at least begins in client-accessible storage. */
- if (!VG_(am_is_valid_for_client)( ARG2, 1, VKI_PROT_READ )) {
+ if (ARG2 == 0 /* obviously bogus */
+ || !VG_(am_is_valid_for_client)( ARG2, 1, VKI_PROT_READ )) {
SET_STATUS_Failure( VKI_EFAULT );
return;
}
+ // Decide whether or not we want to follow along
+ trace_this_child = VG_(should_we_trace_this_child)( (HChar*)ARG2 );
+
// Do the important checks: it is a file, is executable, permissions are
// ok, etc. We allow setuid executables to run only in the case when
// we are not simulating them, that is, they to be run natively.
- res = simple_pre_exec_check((const HChar*)ARG2);
+ res = simple_pre_exec_check( (const HChar*)ARG2, trace_this_child );
if (sr_isError(res)) {
SET_STATUS_Failure( sr_Err(res) );
return;
@@ -2639,7 +2645,7 @@
/* If we're tracing the child, and the launcher name looks bogus
(possibly because launcher.c couldn't figure it out, see
comments therein) then we have no option but to fail. */
- if (VG_(clo_trace_children)
+ if (trace_this_child
&& (VG_(name_of_launcher) == NULL
|| VG_(name_of_launcher)[0] != '/')) {
SET_STATUS_Failure( VKI_ECHILD ); /* "No child processes" */
@@ -2651,7 +2657,7 @@
// Set up the child's exe path.
//
- if (VG_(clo_trace_children)) {
+ if (trace_this_child) {
// We want to exec the launcher. Get its pre-remembered path.
path = VG_(name_of_launcher);
@@ -2685,7 +2691,7 @@
VG_(env_remove_valgrind_env_stuff)( envp );
}
- if (VG_(clo_trace_children)) {
+ if (trace_this_child) {
// Set VALGRIND_LIB in ARG5 (the environment)
VG_(env_setenv)( &envp, VALGRIND_LIB, VG_(libdir));
}
@@ -2698,7 +2704,7 @@
// except that the first VG_(args_for_valgrind_noexecpass) args
// are omitted.
//
- if (!VG_(clo_trace_children)) {
+ if (!trace_this_child) {
argv = (Char**)ARG4;
} else {
vg_assert( VG_(args_for_valgrind) );
Modified: trunk/coregrind/m_syswrap/syswrap-generic.c
===================================================================
--- trunk/coregrind/m_syswrap/syswrap-generic.c 2009-11-05 08:43:38 UTC (rev 10926)
+++ trunk/coregrind/m_syswrap/syswrap-generic.c 2009-11-05 08:55:13 UTC (rev 10927)
@@ -2488,7 +2488,7 @@
ThreadState* tst;
Int i, j, tot_args;
SysRes res;
- Bool setuid_allowed;
+ Bool setuid_allowed, trace_this_child;
PRINT("sys_execve ( %#lx(%s), %#lx, %#lx )", ARG1, (char*)ARG1, ARG2, ARG3);
PRE_REG_READ3(vki_off_t, "execve",
@@ -2510,15 +2510,19 @@
doing it. */
/* Check that the name at least begins in client-accessible storage. */
- if (!VG_(am_is_valid_for_client)( ARG1, 1, VKI_PROT_READ )) {
+ if (ARG1 == 0 /* obviously bogus */
+ || !VG_(am_is_valid_for_client)( ARG1, 1, VKI_PROT_READ )) {
SET_STATUS_Failure( VKI_EFAULT );
return;
}
+ // Decide whether or not we want to follow along
+ trace_this_child = VG_(should_we_trace_this_child)( (HChar*)ARG1 );
+
// Do the important checks: it is a file, is executable, permissions are
// ok, etc. We allow setuid executables to run only in the case when
// we are not simulating them, that is, they to be run natively.
- setuid_allowed = VG_(clo_trace_children) ? False : True;
+ setuid_allowed = trace_this_child ? False : True;
res = VG_(pre_exec_check)((const Char*)ARG1, NULL, setuid_allowed);
if (sr_isError(res)) {
SET_STATUS_Failure( sr_Err(res) );
@@ -2528,7 +2532,7 @@
/* If we're tracing the child, and the launcher name looks bogus
(possibly because launcher.c couldn't figure it out, see
comments therein) then we have no option but to fail. */
- if (VG_(clo_trace_children)
+ if (trace_this_child
&& (VG_(name_of_launcher) == NULL
|| VG_(name_of_launcher)[0] != '/')) {
SET_STATUS_Failure( VKI_ECHILD ); /* "No child processes" */
@@ -2546,7 +2550,7 @@
// Set up the child's exe path.
//
- if (VG_(clo_trace_children)) {
+ if (trace_this_child) {
// We want to exec the launcher. Get its pre-remembered path.
path = VG_(name_of_launcher);
@@ -2584,7 +2588,7 @@
VG_(env_remove_valgrind_env_stuff)( envp );
}
- if (VG_(clo_trace_children)) {
+ if (trace_this_child) {
// Set VALGRIND_LIB in ARG3 (the environment)
VG_(env_setenv)( &envp, VALGRIND_LIB, VG_(libdir));
}
@@ -2597,7 +2601,7 @@
// except that the first VG_(args_for_valgrind_noexecpass) args
// are omitted.
//
- if (!VG_(clo_trace_children)) {
+ if (!trace_this_child) {
argv = (Char**)ARG2;
} else {
vg_assert( VG_(args_for_valgrind) );
Modified: trunk/coregrind/pub_core_options.h
===================================================================
--- trunk/coregrind/pub_core_options.h 2009-11-05 08:43:38 UTC (rev 10926)
+++ trunk/coregrind/pub_core_options.h 2009-11-05 08:55:13 UTC (rev 10927)
@@ -61,6 +61,9 @@
extern Bool VG_(clo_demangle);
/* Simulate child processes? default: NO */
extern Bool VG_(clo_trace_children);
+/* String containing comma-separated patterns for executable names
+ that should not be traced into even when --trace-children=yes */
+extern HChar* VG_(clo_trace_children_skip);
/* After a fork, the child's output can become confusingly
intermingled with the parent's output. This is especially
problematic when VG_(clo_xml) is True. Setting
@@ -182,6 +185,10 @@
__attribute__((noreturn))
extern void VG_(err_config_error) ( Char* msg );
+/* Should we trace into this child executable (across execve etc) ?
+ This involves considering --trace-children=, --trace-children-skip=
+ and the name of the executable. */
+extern Bool VG_(should_we_trace_this_child) ( HChar* child_exe_name );
#endif // __PUB_CORE_OPTIONS_H
Modified: trunk/docs/xml/manual-core.xml
===================================================================
--- trunk/docs/xml/manual-core.xml 2009-11-05 08:43:38 UTC (rev 10926)
+++ trunk/docs/xml/manual-core.xml 2009-11-05 08:55:13 UTC (rev 10927)
@@ -660,6 +660,32 @@
</listitem>
</varlistentry>
+ <varlistentry id="opt.trace-children-skip" xreflabel="--trace-children-skip">
+ <term>
+ <option><![CDATA[--trace-children-skip=patt1,patt2 ]]></option>
+ </term>
+ <listitem>
+ <para>This option only has an effect when
+ <option>--trace-children=yes</option> is specified. It allows
+ for some children to be skipped. The option takes a comma
+ separated list of patterns for the names of child executables
+ that Valgrind should not trace into. Patterns may include the
+ metacharacters <computeroutput>?</computeroutput>
+ and <computeroutput>*</computeroutput>, which have the usual
+ meaning.</para>
+ <para>
+ This can be useful for pruning uninteresting branches from a
+ tree of processes being run on Valgrind. But you should be
+ careful when using it. When Valgrind skips tracing into an
+ executable, it doesn't just skip tracing that executable, it
+ also skips tracing any of that executable's child processes.
+ In other words, the flag doesn't merely cause tracing to stop
+ at the specified executables -- it skips tracing of entire
+ process subtrees rooted at any of the specified
+ executables.</para>
+ </listitem>
+ </varlistentry>
+
<varlistentry id="opt.child-silent-after-fork"
xreflabel="--child-silent-after-fork">
<term>
Modified: trunk/none/tests/cmdline1.stdout.exp
===================================================================
--- trunk/none/tests/cmdline1.stdout.exp 2009-11-05 08:43:38 UTC (rev 10926)
+++ trunk/none/tests/cmdline1.stdout.exp 2009-11-05 08:55:13 UTC (rev 10927)
@@ -10,6 +10,8 @@
-q --quiet run silently; only print error msgs
-v --verbose be more verbose -- show misc extra info
--trace-children=no|yes Valgrind-ise child processes (follow execve)? [no]
+ --trace-children-skip=patt1,patt2,... specifies a list of executables
+ that --trace-children=yes should not trace into
--child-silent-after-fork=no|yes omit child output between fork & exec? [no]
--track-fds=no|yes track open file descriptors? [no]
--time-stamp=no|yes add timestamps to log messages? [no]
Modified: trunk/none/tests/cmdline2.stdout.exp
===================================================================
--- trunk/none/tests/cmdline2.stdout.exp 2009-11-05 08:43:38 UTC (rev 10926)
+++ trunk/none/tests/cmdline2.stdout.exp 2009-11-05 08:55:13 UTC (rev 10927)
@@ -10,6 +10,8 @@
-q --quiet run silently; only print error msgs
-v --verbose be more verbose -- show misc extra info
--trace-children=no|yes Valgrind-ise child processes (follow execve)? [no]
+ --trace-children-skip=patt1,patt2,... specifies a list of executables
+ that --trace-children=yes should not trace into
--child-silent-after-fork=no|yes omit child output between fork & exec? [no]
--track-fds=no|yes track open file descriptors? [no]
--time-stamp=no|yes add timestamps to log messages? [no]
|
|
From: <sv...@va...> - 2009-11-05 08:43:55
|
Author: sewardj
Date: 2009-11-05 08:43:38 +0000 (Thu, 05 Nov 2009)
New Revision: 10926
Log:
Correctly handle MPI_STATUS{ES}_IGNORE as valid values for
MPI_Status* arguments (as opposed to segfaulting :-)
Modified:
trunk/mpi/libmpiwrap.c
Modified: trunk/mpi/libmpiwrap.c
===================================================================
--- trunk/mpi/libmpiwrap.c 2009-11-03 21:14:31 UTC (rev 10925)
+++ trunk/mpi/libmpiwrap.c 2009-11-05 08:43:38 UTC (rev 10926)
@@ -57,7 +57,33 @@
without prior written permission.
*/
+/* Handling of MPI_STATUS{ES}_IGNORE for MPI_Status* arguments.
+ The MPI-2 spec allows many functions which have MPI_Status* purely
+ as an out parameter, to accept the constants MPI_STATUS_IGNORE or
+ MPI_STATUSES_IGNORE there instead, if the caller does not care
+ about the status. See the MPI-2 spec sec 4.5.1 ("Passing
+ MPI_STATUS_IGNORE for Status"). (mpi2-report.pdf, 1615898 bytes,
+ md5=694a5efe2fd291eecf7e8c9875b5f43f).
+
+ This library handles such cases by allocating a fake MPI_Status
+ object (on the stack) or an array thereof (on the heap), and
+ passing that onwards instead. From the outside the caller sees no
+ difference. Unfortunately the simpler approach of merely detecting
+ and handling these special cases at a lower level does not work,
+ because we need to use information returned in MPI_Status*
+ arguments to paint result buffers, even if the caller doesn't
+ supply a real MPI_Status object.
+
+ Eg, MPI_Recv. We can't paint the result buffer without knowing how
+ many items arrived; but we can't find that out without passing a
+ real MPI_Status object to the (real) MPI_Recv call. Hence, if the
+ caller did not supply one, we have no option but to use a temporary
+ stack allocated one for the inner call. Ditto, more indirectly
+ (via maybe_complete) for nonblocking receives and the various
+ associated wait/test calls. */
+
+
/*------------------------------------------------------------*/
/*--- includes ---*/
/*------------------------------------------------------------*/
@@ -103,6 +129,17 @@
#endif
+/* Define HAVE_MPI_STATUS_IGNORE iff we have to deal with
+ MPI_STATUS{ES}_IGNORE. */
+#if MPI_VERSION >= 2 \
+ || (defined(MPI_STATUS_IGNORE) && defined(MPI_STATUSES_IGNORE))
+# undef HAVE_MPI_STATUS_IGNORE
+# define HAVE_MPI_STATUS_IGNORE 1
+#else
+# undef HAVE_MPI_STATUS_IGNORE
+#endif
+
+
/*------------------------------------------------------------*/
/*--- Decls ---*/
/*------------------------------------------------------------*/
@@ -401,6 +438,20 @@
return r1 == r2;
}
+/* Return True if status is MPI_STATUS_IGNORE or MPI_STATUSES_IGNORE.
+ On MPI-1.x platforms which don't have these symbols (and they would
+ only have them if they've been backported from 2.x) always return
+ False. */
+static __inline__
+Bool isMSI ( MPI_Status* status )
+{
+# if defined(HAVE_MPI_STATUS_IGNORE)
+ return status == MPI_STATUSES_IGNORE || status == MPI_STATUS_IGNORE;
+# else
+ return False;
+# endif
+}
+
/* Get the 'extent' of a type. Note, as per the MPI spec this
includes whatever padding would be required when using 'ty' in an
array. */
@@ -1045,10 +1096,13 @@
int source, int tag,
MPI_Comm comm, MPI_Status *status)
{
- OrigFn fn;
- int err, recv_count = 0;
+ OrigFn fn;
+ int err, recv_count = 0;
+ MPI_Status fake_status;
VALGRIND_GET_ORIG_FN(fn);
before("Recv");
+ if (isMSI(status))
+ status = &fake_status;
check_mem_is_addressable(buf, count, datatype);
check_mem_is_addressable_untyped(status, sizeof(*status));
CALL_FN_W_7W(err, fn, buf,count,datatype,source,tag,comm,status);
@@ -1386,10 +1440,13 @@
MPI_Status* status )
{
MPI_Request request_before;
+ MPI_Status fake_status;
OrigFn fn;
int err;
VALGRIND_GET_ORIG_FN(fn);
before("Wait");
+ if (isMSI(status))
+ status = &fake_status;
check_mem_is_addressable_untyped(status, sizeof(MPI_Status));
check_mem_is_defined_untyped(request, sizeof(MPI_Request));
request_before = *request;
@@ -1410,10 +1467,13 @@
MPI_Status* status )
{
MPI_Request* requests_before = NULL;
+ MPI_Status fake_status;
OrigFn fn;
int err, i;
VALGRIND_GET_ORIG_FN(fn);
before("Waitany");
+ if (isMSI(status))
+ status = &fake_status;
if (0) fprintf(stderr, "Waitany: %d\n", count);
check_mem_is_addressable_untyped(index, sizeof(int));
check_mem_is_addressable_untyped(status, sizeof(MPI_Status));
@@ -1441,9 +1501,14 @@
MPI_Request* requests_before = NULL;
OrigFn fn;
int err, i;
+ Bool free_sta = False;
VALGRIND_GET_ORIG_FN(fn);
before("Waitall");
if (0) fprintf(stderr, "Waitall: %d\n", count);
+ if (isMSI(statuses)) {
+ free_sta = True;
+ statuses = malloc( (count < 0 ? 0 : count) * sizeof(MPI_Status) );
+ }
for (i = 0; i < count; i++) {
check_mem_is_addressable_untyped(&statuses[i], sizeof(MPI_Status));
check_mem_is_defined_untyped(&requests[i], sizeof(MPI_Request));
@@ -1462,6 +1527,8 @@
}
if (requests_before)
free(requests_before);
+ if (free_sta)
+ free(statuses);
after("Waitall", err);
return err;
}
@@ -1472,10 +1539,13 @@
MPI_Status* status )
{
MPI_Request request_before;
+ MPI_Status fake_status;
OrigFn fn;
int err;
VALGRIND_GET_ORIG_FN(fn);
before("Test");
+ if (isMSI(status))
+ status = &fake_status;
check_mem_is_addressable_untyped(status, sizeof(MPI_Status));
check_mem_is_addressable_untyped(flag, sizeof(int));
check_mem_is_defined_untyped(request, sizeof(MPI_Request));
@@ -1498,9 +1568,14 @@
MPI_Request* requests_before = NULL;
OrigFn fn;
int err, i;
+ Bool free_sta = False;
VALGRIND_GET_ORIG_FN(fn);
before("Testall");
if (0) fprintf(stderr, "Testall: %d\n", count);
+ if (isMSI(statuses)) {
+ free_sta = True;
+ statuses = malloc( (count < 0 ? 0 : count) * sizeof(MPI_Status) );
+ }
check_mem_is_addressable_untyped(flag, sizeof(int));
for (i = 0; i < count; i++) {
check_mem_is_addressable_untyped(&statuses[i], sizeof(MPI_Status));
@@ -1516,11 +1591,14 @@
for (i = 0; i < count; i++) {
maybe_complete(e_i_s, requests_before[i], requests[i],
&statuses[i]);
- make_mem_defined_if_addressable_untyped(&statuses[i], sizeof(MPI_Status));
+ make_mem_defined_if_addressable_untyped(&statuses[i],
+ sizeof(MPI_Status));
}
}
if (requests_before)
free(requests_before);
+ if (free_sta)
+ free(statuses);
after("Testall", err);
return err;
}
@@ -1533,10 +1611,13 @@
MPI_Comm comm,
int* flag, MPI_Status* status)
{
- OrigFn fn;
- int err;
+ MPI_Status fake_status;
+ OrigFn fn;
+ int err;
VALGRIND_GET_ORIG_FN(fn);
before("Iprobe");
+ if (isMSI(status))
+ status = &fake_status;
check_mem_is_addressable_untyped(flag, sizeof(*flag));
check_mem_is_addressable_untyped(status, sizeof(*status));
CALL_FN_W_5W(err, fn, source,tag,comm,flag,status);
@@ -1555,10 +1636,13 @@
int WRAPPER_FOR(PMPI_Probe)(int source, int tag,
MPI_Comm comm, MPI_Status* status)
{
- OrigFn fn;
- int err;
+ MPI_Status fake_status;
+ OrigFn fn;
+ int err;
VALGRIND_GET_ORIG_FN(fn);
before("Probe");
+ if (isMSI(status))
+ status = &fake_status;
check_mem_is_addressable_untyped(status, sizeof(*status));
CALL_FN_W_WWWW(err, fn, source,tag,comm,status);
make_mem_defined_if_addressable_if_success_untyped(err, status, sizeof(*status));
@@ -1606,12 +1690,16 @@
int source, int recvtag,
MPI_Comm comm, MPI_Status *status)
{
- OrigFn fn;
- int err, recvcount_actual = 0;
+ MPI_Status fake_status;
+ OrigFn fn;
+ int err, recvcount_actual = 0;
VALGRIND_GET_ORIG_FN(fn);
before("Sendrecv");
+ if (isMSI(status))
+ status = &fake_status;
check_mem_is_defined(sendbuf, sendcount, sendtype);
check_mem_is_addressable(recvbuf, recvcount, recvtype);
+ check_mem_is_addressable_untyped(status, sizeof(*status));
CALL_FN_W_12W(err, fn, sendbuf,sendcount,sendtype,dest,sendtag,
recvbuf,recvcount,recvtype,source,recvtag,
comm,status);
|
|
From: Julian S. <js...@ac...> - 2009-11-05 08:01:45
|
On Thursday 05 November 2009, Konstantin Serebryany wrote: > I think this section of helgrind docs is generally out of date (Julian, > please confirm). > Helgrind 3.5 is a pure happens-before detector and thus handles this case > correctly. > Same for DRD. Unfortunately I think the docs are correct, and neither Helgrind nor DRD can handle this properly. The basic problem is that there can be a h-b dependency which arises from the loop and values in memory, not from the mx or cv, so the dependency is "invisible". I believe Laszlo's comments are valid and correct, and an interesting solution. I'd have to stare at it more it be convinced it's correct, but it looks plausible. Laszlo, can you explain the background to this a bit? How did you come to be looking at this problem? Does your solution help? J |
|
From: Konstantin S. <kon...@gm...> - 2009-11-05 05:13:22
|
On Wed, Nov 4, 2009 at 11:52 PM, ERSEK Laszlo <la...@ca...> wrote: > Hi, > > [0] states: > > > ---------- > 7.5. Hints and Tips for Effective Use of Helgrind > > 3. Avoid POSIX condition variables > > [...] > > a solution to this problem that does not require source-level > annotation of condition-variable wait loops is beyond the current > state of the art. > I think this section of helgrind docs is generally out of date (Julian, please confirm). Helgrind 3.5 is a pure happens-before detector and thus handles this case correctly. Same for DRD. If you want a hybrid detector (which finds more races and is more stable, but does indeed choke on cond vars), see e.g. here: http://code.google.com/p/data-race-test/wiki/DynamicAnnotations#pthread_cond_wait_loop --kcc > ---------- > > > I respectfully ask if the following passage could be recommended for the > Waiter as a code transformation that pessimizes, but does not invalidate > the code. If this qualifies as "source-level annotation of > condition-variable wait loops", then I apologize for the noise. (I > interpret "source-level annotation" as specially formatted comments, or > #pragma's, or Valgrind-specific API calls etc.) > > > ---------- > If your original code looks (as it should look) like > > pthread_mutex_lock(mx); > while (!b) { > pthread_cond_wait(cv, mx); > } > pthread_mutex_unlock(mx); > > Then consider inserting the following COMPILING_FOR_VALGRIND block: > > pthread_mutex_lock(mx); > > #ifdef COMPILING_FOR_VALGRIND > { > struct timespec epoch; > int ret; > > epoch.tv_sec = 0; > epoch.tv_nsec = 0; > > ret = pthread_cond_timedwait(cv, mx, &epoch); > assert(ETIMEDOUT == ret || 0 == ret); > } > #endif > > while (!b) { > pthread_cond_wait(cv, mx); > } > pthread_mutex_unlock(mx); > ---------- > > 1. The dependency on the condition variable is now unavoidable, no matter > the initial value of "b" right after acquiring "mx"; so Valgrind can see > the dependency unconditionally. > > 2. No matter the value of "ret" (0 or ETIMEDOUT), pthread_cond_timedwait() > will have released and re-acquired mutex "mx"; see [1]. This is new > mutex/condvar activity, but it shouldn't hurt too much performance-wise. > > 3. The clock selection (see [2]) of the condition variable shouldn't > matter with an absolute time barrier set to 0. The epoch of whichever > clock is selected happens in the past, thus pthread_cond_timedwait() > should return immediately. > > 4. pthread_cond_timedwait() introduces a cancellation point. This is > nothing new if (!b) holds, because pthread_cond_wait() is a cancellation > point anyway. If "b" is true, however, this cancellation point is new. > Shouldn't hurt too much, since the original waiter code can't predict the > value of "b" either, so it must be prepared for cancellation anyway. > > 5. If "ret" is ETIMEDOUT, then we've received no signal/broadcast for > sure; back to business as usual. If "ret" is 0, we have received a > signal/broadcast (or a spurious wakeup), but we'll still check "b" first, > so the code stays valid. > > > As said above, I apologize if this is obvious and already covered by the > exclusion of "source-level annotation". > > Thanks, > lacos > > [0] http://valgrind.org/docs/manual/hg-manual.html#hg-manual.effective-use > [1] > http://www.opengroup.org/onlinepubs/000095399/functions/pthread_cond_timedwait.html > [2] http://valgrind.org/docs/manual/drd-manual.html#drd-manual.pctw > > > ------------------------------------------------------------------------------ > 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: ERSEK L. <la...@ca...> - 2009-11-04 21:29:33
|
Hi,
[0] states:
----------
7.5. Hints and Tips for Effective Use of Helgrind
3. Avoid POSIX condition variables
[...]
a solution to this problem that does not require source-level
annotation of condition-variable wait loops is beyond the current
state of the art.
----------
I respectfully ask if the following passage could be recommended for the
Waiter as a code transformation that pessimizes, but does not invalidate
the code. If this qualifies as "source-level annotation of
condition-variable wait loops", then I apologize for the noise. (I
interpret "source-level annotation" as specially formatted comments, or
#pragma's, or Valgrind-specific API calls etc.)
----------
If your original code looks (as it should look) like
pthread_mutex_lock(mx);
while (!b) {
pthread_cond_wait(cv, mx);
}
pthread_mutex_unlock(mx);
Then consider inserting the following COMPILING_FOR_VALGRIND block:
pthread_mutex_lock(mx);
#ifdef COMPILING_FOR_VALGRIND
{
struct timespec epoch;
int ret;
epoch.tv_sec = 0;
epoch.tv_nsec = 0;
ret = pthread_cond_timedwait(cv, mx, &epoch);
assert(ETIMEDOUT == ret || 0 == ret);
}
#endif
while (!b) {
pthread_cond_wait(cv, mx);
}
pthread_mutex_unlock(mx);
----------
1. The dependency on the condition variable is now unavoidable, no matter
the initial value of "b" right after acquiring "mx"; so Valgrind can see
the dependency unconditionally.
2. No matter the value of "ret" (0 or ETIMEDOUT), pthread_cond_timedwait()
will have released and re-acquired mutex "mx"; see [1]. This is new
mutex/condvar activity, but it shouldn't hurt too much performance-wise.
3. The clock selection (see [2]) of the condition variable shouldn't
matter with an absolute time barrier set to 0. The epoch of whichever
clock is selected happens in the past, thus pthread_cond_timedwait()
should return immediately.
4. pthread_cond_timedwait() introduces a cancellation point. This is
nothing new if (!b) holds, because pthread_cond_wait() is a cancellation
point anyway. If "b" is true, however, this cancellation point is new.
Shouldn't hurt too much, since the original waiter code can't predict the
value of "b" either, so it must be prepared for cancellation anyway.
5. If "ret" is ETIMEDOUT, then we've received no signal/broadcast for
sure; back to business as usual. If "ret" is 0, we have received a
signal/broadcast (or a spurious wakeup), but we'll still check "b" first,
so the code stays valid.
As said above, I apologize if this is obvious and already covered by the
exclusion of "source-level annotation".
Thanks,
lacos
[0] http://valgrind.org/docs/manual/hg-manual.html#hg-manual.effective-use
[1] http://www.opengroup.org/onlinepubs/000095399/functions/pthread_cond_timedwait.html
[2] http://valgrind.org/docs/manual/drd-manual.html#drd-manual.pctw
|
|
From: Bart V. A. <bar...@gm...> - 2009-11-04 08:36:19
|
Nightly build on cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) Started at 2009-11-04 02:22:58 EST Ended at 2009-11-04 03:35:59 EST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Last 20 lines of verbose log follow echo gcc -Winline -Wall -Wshadow -g -m64 -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -fno-stack-protector -o clientperm clientperm.o gcc -Winline -Wall -Wshadow -g -m64 -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -fno-stack-protector -o custom_alloc custom_alloc.o gcc -Winline -Wall -Wshadow -g -m64 -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -fno-stack-protector -o custom-overlap custom-overlap.o source='deep_templates.cpp' object='deep_templates-deep_templates.o' libtool=no \ DEPDIR=.deps depmode=none /bin/sh ../../depcomp \ g++ -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../include -I../../coregrind -I../../include -I../../VEX/pub -DVGA_ppc64=1 -DVGO_linux=1 -DVGP_ppc64_linux=1 -Winline -Wall -Wshadow -g -m64 -O -gstabs -c -o deep_templates-deep_templates.o `test -f 'deep_templates.cpp' || echo './'`deep_templates.cpp ../../depcomp: line 566: exec: g++: not found make[6]: *** [deep_templates-deep_templates.o] Error 127 make[6]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-new/memcheck/tests' make[5]: *** [check-am] Error 2 make[5]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-new/memcheck/tests' make[4]: *** [check-recursive] Error 1 make[4]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-new/memcheck/tests' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-new/memcheck' make[2]: *** [check] Error 2 make[2]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-new/memcheck' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-new' make: *** [check] Error 2 ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Last 20 lines of verbose log follow echo gcc -Winline -Wall -Wshadow -g -m64 -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -fno-stack-protector -o clientperm clientperm.o gcc -Winline -Wall -Wshadow -g -m64 -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -fno-stack-protector -o custom_alloc custom_alloc.o gcc -Winline -Wall -Wshadow -g -m64 -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -fno-stack-protector -o custom-overlap custom-overlap.o source='deep_templates.cpp' object='deep_templates-deep_templates.o' libtool=no \ DEPDIR=.deps depmode=none /bin/sh ../../depcomp \ g++ -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../include -I../../coregrind -I../../include -I../../VEX/pub -DVGA_ppc64=1 -DVGO_linux=1 -DVGP_ppc64_linux=1 -Winline -Wall -Wshadow -g -m64 -O -gstabs -c -o deep_templates-deep_templates.o `test -f 'deep_templates.cpp' || echo './'`deep_templates.cpp ../../depcomp: line 566: exec: g++: not found make[6]: *** [deep_templates-deep_templates.o] Error 127 make[6]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-old/memcheck/tests' make[5]: *** [check-am] Error 2 make[5]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-old/memcheck/tests' make[4]: *** [check-recursive] Error 1 make[4]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-old/memcheck/tests' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-old/memcheck' make[2]: *** [check] Error 2 make[2]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-old/memcheck' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-old' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Nov 4 02:59:29 2009 --- new.short Wed Nov 4 03:35:59 2009 *************** *** 15,27 **** make[6]: *** [deep_templates-deep_templates.o] Error 127 ! make[6]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-old/memcheck/tests' make[5]: *** [check-am] Error 2 ! make[5]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-old/memcheck/tests' make[4]: *** [check-recursive] Error 1 ! make[4]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-old/memcheck/tests' make[3]: *** [check-recursive] Error 1 ! make[3]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-old/memcheck' make[2]: *** [check] Error 2 ! make[2]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-old/memcheck' make[1]: *** [check-recursive] Error 1 ! make[1]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-old' make: *** [check] Error 2 --- 15,27 ---- make[6]: *** [deep_templates-deep_templates.o] Error 127 ! make[6]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-new/memcheck/tests' make[5]: *** [check-am] Error 2 ! make[5]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-new/memcheck/tests' make[4]: *** [check-recursive] Error 1 ! make[4]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-new/memcheck/tests' make[3]: *** [check-recursive] Error 1 ! make[3]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-new/memcheck' make[2]: *** [check] Error 2 ! make[2]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-new/memcheck' make[1]: *** [check-recursive] Error 1 ! make[1]: Leaving directory `/net/home/bart/software/valgrind/nightly/valgrind-new' make: *** [check] Error 2 |
|
From: Nicholas N. <n.n...@gm...> - 2009-11-04 03:51:17
|
On Wed, Nov 4, 2009 at 7:14 AM, Dodji Seketeli <do...@re...> wrote: > > Just curious, is there an IRC channel where valgrind hackers join to > discuss about development topics ? No. Nick |
|
From: Tom H. <th...@cy...> - 2009-11-04 03:50:12
|
Nightly build on vauxhall ( x86_64, Fedora 11 ) Started at 2009-11-04 03:20:06 GMT Ended at 2009-11-04 03:49:47 GMT 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 == 541 tests, 9 stderr failures, 1 stdout failure, 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/pth_detached_sem (stdout) drd/tests/qt4_mutex (stderr) drd/tests/qt4_rwlock (stderr) drd/tests/qt4_semaphore (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 == 541 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_mutex (stderr) drd/tests/qt4_rwlock (stderr) exp-ptrcheck/tests/bad_percentify (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Nov 4 03:35:08 2009 --- new.short Wed Nov 4 03:49:47 2009 *************** *** 8,10 **** ! == 541 tests, 8 stderr failures, 0 stdout failures, 0 post failures == memcheck/tests/linux/stack_switch (stderr) --- 8,10 ---- ! == 541 tests, 9 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/linux/stack_switch (stderr) *************** *** 14,17 **** --- 14,19 ---- helgrind/tests/tc23_bogus_condwait (stderr) + drd/tests/pth_detached_sem (stdout) drd/tests/qt4_mutex (stderr) drd/tests/qt4_rwlock (stderr) + drd/tests/qt4_semaphore (stderr) exp-ptrcheck/tests/bad_percentify (stderr) |
|
From: Tom H. <th...@cy...> - 2009-11-04 03:48:50
|
Nightly build on lloyd ( x86_64, Fedora 7 ) Started at 2009-11-04 03:05:05 GMT Ended at 2009-11-04 03:48:31 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 531 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) |
|
From: Tom H. <th...@cy...> - 2009-11-04 03:36:04
|
Nightly build on mg ( x86_64, Fedora 9 ) Started at 2009-11-04 03:10:08 GMT Ended at 2009-11-04 03:35:44 GMT 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 == 538 tests, 2 stderr failures, 0 stdout failures, 0 post failures == helgrind/tests/pth_spinlock (stderr) 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 == 538 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 Wed Nov 4 03:23:02 2009 --- new.short Wed Nov 4 03:35:44 2009 *************** *** 8,10 **** ! == 538 tests, 1 stderr failure, 0 stdout failures, 0 post failures == helgrind/tests/tc06_two_races_xml (stderr) --- 8,11 ---- ! == 538 tests, 2 stderr failures, 0 stdout failures, 0 post failures == ! helgrind/tests/pth_spinlock (stderr) helgrind/tests/tc06_two_races_xml (stderr) |
|
From: <sv...@va...> - 2009-11-03 21:14:48
|
Author: tom
Date: 2009-11-03 21:14:31 +0000 (Tue, 03 Nov 2009)
New Revision: 10925
Log:
Rework VG_(memmove) in the case where the destination address is greater
that the source address to use the same logic as the mc_replace_strmem.c
version so that underflow is avoided. Fixes #211008.
Modified:
trunk/coregrind/m_libcbase.c
Modified: trunk/coregrind/m_libcbase.c
===================================================================
--- trunk/coregrind/m_libcbase.c 2009-11-03 21:02:16 UTC (rev 10924)
+++ trunk/coregrind/m_libcbase.c 2009-11-03 21:14:31 UTC (rev 10925)
@@ -437,8 +437,8 @@
}
}
else if (dest > src) {
- for (i = sz - 1; i >= 0; i--) {
- ((UChar*)dest)[i] = ((UChar*)src)[i];
+ for (i = 0; i < sz; i++) {
+ ((UChar*)dest)[sz-i-1] = ((UChar*)src)[sz-i-1];
}
}
return dest;
|