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
(32) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
1
(20) |
2
(20) |
3
(11) |
4
(10) |
5
(11) |
6
(19) |
|
7
(12) |
8
(22) |
9
(22) |
10
(18) |
11
(11) |
12
(21) |
13
(17) |
|
14
(8) |
15
(16) |
16
(16) |
17
(9) |
18
(19) |
19
(12) |
20
(9) |
|
21
(8) |
22
(12) |
23
(17) |
24
(8) |
25
(8) |
26
(7) |
27
(11) |
|
28
(12) |
29
(16) |
30
(16) |
31
(9) |
|
|
|
|
From: <js...@ac...> - 2007-01-04 01:16:07
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-01-04 02:00:01 CET 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 == 223 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: <js...@ac...> - 2007-01-03 06:17:43
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2007-01-03 09:00:02 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 == 217 tests, 10 stderr failures, 6 stdout failures, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-fp (stderr) none/tests/ppc32/round (stdout) none/tests/ppc32/round (stderr) none/tests/ppc32/test_fx (stdout) none/tests/ppc32/test_fx (stderr) none/tests/ppc32/test_gx (stdout) |
|
From: <js...@ac...> - 2007-01-03 05:05:51
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2007-01-03 04:30:01 GMT Checking out vex source tree ... done Building vex ... done Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 250 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <to...@co...> - 2007-01-03 03:55:30
|
Nightly build on dunsmere ( athlon, Fedora Core 6 ) started at 2007-01-03 03:30:06 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 == 252 tests, 5 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_detached (stdout) |
|
From: Tom H. <th...@cy...> - 2007-01-03 03:23:37
|
Nightly build on dellow ( x86_64, Fedora Core 6 ) started at 2007-01-03 03:10:03 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 == 281 tests, 4 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2007-01-03 03:16:33
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2007-01-03 03:05:04 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 == 281 tests, 5 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2007-01-03 03:10:47
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-01-03 03:00:02 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 == 283 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: <js...@ac...> - 2007-01-03 01:16:13
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-01-03 02:00:01 CET 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 == 223 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: <bro...@co...> - 2007-01-03 00:24:05
|
Agreed Tom. I will use a set of strace runs to evaluate and return more meaningful output asap - sometime tomorrow when I get back to our labs. The application provides voluminous logging so I should be able to pull something. Mostly what I have observed though is that the identity piece fails immediately and then the log says the system failed to initialize communications. It could very likely be a function of how the JXTA componentry gets invoked, but as Nicolas points out, all of that should be transparent (or rather, irrelevant) to valgrind as valgrind is working at the register/stack/instruction set level. -- Bruce Rosenthal Chief Architect, TranStrophe Turning Information and Technology Into Business Opportunities 510 690 0877 510 432 7912 www.transtrophe.com -------------- Original message -------------- From: Tom Hughes <to...@co...> > In message > <010320070007.29840.459AF3D200090D80000074902206824693089B020A9C019D0D@comcast.n > et> > bro...@co... wrote: > > > Using Valgrind 3.2.1. > > > > Actually, Valgrind is not failing - it runs as it should. Rather, it is > > just the application that is trying to run WITHIN the Valgrind "processor" > > that is failing. > > > > Again, the application fails on establishing the "communication machinery", > > which is dependent on having certain identity checks passing succesfully. > > I think you need to drill deeper into exactly what is failing in your > application then - you are talking about a rather high level concept > failing as I understand things. > > Presumably if you drill down into that routine you will find some > system call that is not doing what you expect or something... That > will be a lot more helpful in trying to diagnose the problem than > what you have managed to give us so far. > > Tom > > -- > Tom Hughes (to...@co...) > http://www.compton.nu/ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: <bro...@co...> - 2007-01-03 00:16:45
|
I will try using strace - should have thought of that. Oh well, rushed to get into the holiday mode after getting the system environment set-up. For what it is worth, the system is in the development stage of it's lifecycle. The version I am working with is a full quality tested release, and as I mentioned, it DOES run correctly in non-valgrindized mode. Also, the way in which the application is invoked is: 1. A "Process Manager" invokes a 2. System Manager which sources an XML control file to activate whatever applications have been configured for start-up. This System Manager will invoke the JXTA-based discovery server where all the other services the system is composed of will register capabilities and be exposed for discovery. I am thinking that because of the overhead associated with translating the instruction sets of the binary into their valgrind representations, the timing of the system is getting messed up which is causing the sytstem to fail its normal initailization routines. -- Bruce Rosenthal Chief Architect, TranStrophe Turning Information and Technology Into Business Opportunities 510 690 0877 510 432 7912 www.transtrophe.com -------------- Original message -------------- From: John Reiser <jreiser@BitWagon.com> > bro...@co... wrote: > > I am attempting to evaluate a complex system using callgrind and cachegrind. > When I invoke the system it fails to initialize as it does on normal operational > mode. ... > > > And I am not really sure what guidance I need, but I suppose a starting point > is > whether there is a way to see what is happening in terms of valgrind > translations > of the operational instruction sets. > > strace still works to reveal system calls. For instance: > strace -f -o strace.out valgrind --tool=callgrind ... > which often produces voluminous output. > > To limit the trace to system calls involving filenames, which might be > an interesting observation point between full strace and nothing: > strace -f -o strace.out -e trace=file valgrind --tool=callgrind ... > Other options can tailor the trace to include read/write/seek/socket etc. > strace also can be attached dynamically; see the manual page. > > Beyond strace there is systemtap (experimental) on recent versions of Fedora > Core. > > Another suggestion is to prune the instances of valgrind until the problem > goes away. Omit applying valgrind at the outermost level, and/or at the > innermost level (replace the innermost level by a shell script that invokes > the original innermost executable without calling valgrind), etc. > > -- > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Tom H. <to...@co...> - 2007-01-03 00:12:15
|
In message <010...@co...>
bro...@co... wrote:
> Using Valgrind 3.2.1.
>
> Actually, Valgrind is not failing - it runs as it should. Rather, it is
> just the application that is trying to run WITHIN the Valgrind "processor"
> that is failing.
>
> Again, the application fails on establishing the "communication machinery",
> which is dependent on having certain identity checks passing succesfully.
I think you need to drill deeper into exactly what is failing in your
application then - you are talking about a rather high level concept
failing as I understand things.
Presumably if you drill down into that routine you will find some
system call that is not doing what you expect or something... That
will be a lot more helpful in trying to diagnose the problem than
what you have managed to give us so far.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: <bro...@co...> - 2007-01-03 00:07:53
|
Using Valgrind 3.2.1. Actually, Valgrind is not failing - it runs as it should. Rather, it is just the application that is trying to run WITHIN the Valgrind "processor" that is failing. Again, the application fails on establishing the "communication machinery", which is dependent on having certain identity checks passing succesfully. -- Bruce Rosenthal Chief Architect, TranStrophe Turning Information and Technology Into Business Opportunities 510 690 0877 510 432 7912 www.transtrophe.com -------------- Original message -------------- From: Nicholas Nethercote <nj...@cs...> > On Tue, 2 Jan 2007 bro...@co... wrote: > > > I am attempting to evaluate a complex system using callgrind and > > cachegrind. When I invoke the system it fails to initialize as it does on > > normal operational mode. My call is as follows, as an example: > > > > root@myhost>valgrind --tool=callgrind --dump-instr=yes --trace-jumps=yes > the.path.to.the.app > > > > Now the system is quite complex and essentially creates and instantiates > > multiple objects including a JXTA-based discovery server object, identity > > checking objects, read and write connection listeners and acceptors, > > policy dissemination objects etc... > > > > The main problem is that the identity object's methods to authenticate the > > calling subject always is failing so all the initial communications set-up > > fails because nothing happens unless the identitycheck is evaluated as > > succesful. > > All this is irrelevant from Valgrind's point of view. Valgrind mostly works > at the binary level, eg. instructions, system calls, registers, memory > locations, with a few library-level details such as heap blocks allocated > via malloc. > > > I cannot give more details then these abstractions at this time. > > You haven't said how Valgrind fails, what the failing output looks like, > which version you're running, what platform you're using, etc. If you > cannot divulge these things then I doubt anyone will be able to help you. > > > And I am not really sure what guidance I need, but I suppose a starting > > point is whether there is a way to see what is happening in terms of > > valgrind translations of the operational instruction sets. > > > > Or if there is a way to attach to the main processes PIDs after a normal, > > non-valgrindized start-up (I think this is impossibel if I understand the > > way valgrind works as a processor simulator). > > Correct, Valgrind cannot do this. There's a similar tool called Pin, from > Intel, which can do this. > > Nick |
|
From: Julian S. <js...@ac...> - 2007-01-02 23:22:30
|
> Another suggestion is to prune the instances of valgrind until the problem > goes away. Omit applying valgrind at the outermost level, and/or at the > innermost level (replace the innermost level by a shell script that invokes > the original innermost executable without calling valgrind), etc. Also worth trying --tool=none just in case it's something specific just in case it's something specific to cachegrind/callgrind. I doubt it is, but still .. J |
|
From: John R.
|
bro...@co... wrote: > I am attempting to evaluate a complex system using callgrind and cachegrind. When I invoke the system it fails to initialize as it does on normal operational mode. ... > And I am not really sure what guidance I need, but I suppose a starting point is whether there is a way to see what is happening in terms of valgrind translations of the operational instruction sets. strace still works to reveal system calls. For instance: strace -f -o strace.out valgrind --tool=callgrind ... which often produces voluminous output. To limit the trace to system calls involving filenames, which might be an interesting observation point between full strace and nothing: strace -f -o strace.out -e trace=file valgrind --tool=callgrind ... Other options can tailor the trace to include read/write/seek/socket etc. strace also can be attached dynamically; see the manual page. Beyond strace there is systemtap (experimental) on recent versions of Fedora Core. Another suggestion is to prune the instances of valgrind until the problem goes away. Omit applying valgrind at the outermost level, and/or at the innermost level (replace the innermost level by a shell script that invokes the original innermost executable without calling valgrind), etc. -- |
|
From: Nicholas N. <nj...@cs...> - 2007-01-02 22:33:18
|
On Tue, 2 Jan 2007 bro...@co... wrote: > I am attempting to evaluate a complex system using callgrind and > cachegrind. When I invoke the system it fails to initialize as it does on > normal operational mode. My call is as follows, as an example: > > root@myhost>valgrind --tool=callgrind --dump-instr=yes --trace-jumps=yes the.path.to.the.app > > Now the system is quite complex and essentially creates and instantiates > multiple objects including a JXTA-based discovery server object, identity > checking objects, read and write connection listeners and acceptors, > policy dissemination objects etc... > > The main problem is that the identity object's methods to authenticate the > calling subject always is failing so all the initial communications set-up > fails because nothing happens unless the identitycheck is evaluated as > succesful. All this is irrelevant from Valgrind's point of view. Valgrind mostly works at the binary level, eg. instructions, system calls, registers, memory locations, with a few library-level details such as heap blocks allocated via malloc. > I cannot give more details then these abstractions at this time. You haven't said how Valgrind fails, what the failing output looks like, which version you're running, what platform you're using, etc. If you cannot divulge these things then I doubt anyone will be able to help you. > And I am not really sure what guidance I need, but I suppose a starting > point is whether there is a way to see what is happening in terms of > valgrind translations of the operational instruction sets. > > Or if there is a way to attach to the main processes PIDs after a normal, > non-valgrindized start-up (I think this is impossibel if I understand the > way valgrind works as a processor simulator). Correct, Valgrind cannot do this. There's a similar tool called Pin, from Intel, which can do this. Nick |
|
From: <bro...@co...> - 2007-01-02 22:16:07
|
I am attempting to evaluate a complex system using callgrind and cachegrind. When I invoke the system it fails to initialize as it does on normal operational mode. My call is as follows, as an example: root@myhost>valgrind --tool=callgrind --dump-instr=yes --trace-jumps=yes the.path.to.the.app Now the system is quite complex and essentially creates and instantiates multiple objects including a JXTA-based discovery server object, identity checking objects, read and write connection listeners and acceptors, policy dissemination objects etc... The main problem is that the identity object's methods to authenticate the calling subject always is failing so all the initial communications set-up fails because nothing happens unless the identitycheck is evaluated as succesful. I cannot give more details then these abstractions at this time. And I am not really sure what guidance I need, but I suppose a starting point is whether there is a way to see what is happening in terms of valgrind translations of the operational instruction sets. Or if there is a way to attach to the main processes PIDs after a normal, non-valgrindized start-up (I think this is impossibel if I understand the way valgrind works as a processor simulator). -- Bruce Rosenthal Chief Architect, TranStrophe Turning Information and Technology Into Business Opportunities 510 690 0877 510 432 7912 www.transtrophe.com |
|
From: Nicholas N. <nj...@cs...> - 2007-01-02 21:40:57
|
On Mon, 1 Jan 2007, Duncan Sands wrote: > thanks for doing this. I gave it a whirl and it seems to work fine. > However it reported a false positive: two threads, thread 1 and thread 2, > write to the same memory location in an unsynchronized way, but they write > *the same value* to it. Thread 1 then reads the value, which may have last > been written by thread 1 or thread 2. This gets reported as a race, even > though there is no race since the value read is independent of the order > in which the threads wrote it: That's a tricky case -- drd doesn't know if those two values will always be the same (in which case it shouldn't issue an error message) or if it just got lucky this time (in which case it should). Nick |
|
From: Julian S. <js...@ac...> - 2007-01-02 15:27:39
|
> 1101167 853 -rw-r--r-- 1 bart users 869782 Jan 2 10:18 > ./branch32/VEX/orig_x86/fpu_mmx_sse.orig > 1101200 1133 -rw-r--r-- 1 bart users 1156810 Jan 2 10:18 > ./branch32/VEX/orig_ppc32/loadsafp.orig > 1101202 1481 -rw-r--r-- 1 bart users 1511720 Jan 2 10:18 > ./branch32/VEX/orig_ppc32/return0.orig > 1101201 3367 -rw-r--r-- 1 bart users 3443743 Jan 2 10:18 > ./branch32/VEX/orig_ppc32/date.orig These are test files used for early development work for vex on x86 and ppc32. They aren't used for production builds and don't get included in the distribution tarball. J |
|
From: Julian S. <js...@ac...> - 2007-01-02 14:40:56
|
On Tuesday 02 January 2007 14:16, Duncan Sands wrote: > > ... Is it possible to generate a suppression pattern with Valgrind's > > option --gen-suppressions=all ? If it is the conflicting accesses are > > triggered by the Ada implementation, I can add them to the default drd > > suppression file. > > I've just discovered that the suppression I sent is almost useless, since > whether it works or not depends strongly on the compiler version, i.e. > while it works for me it most likely will not work for anyone else on Yes - suppressions are like that. You can use wildcards (* and ?) in function names, and/or match on object names rather than function names, in an attempt to make the suppressions more robust to small variants in compiler versions. This often works pretty well, at least it has for writing suppressions for memcheck. Have a look in the top level glibc-2.4.supp file for various examples. J |
|
From: Duncan S. <bal...@fr...> - 2007-01-02 14:17:11
|
> ... Is it possible to generate a suppression pattern with Valgrind's option > --gen-suppressions=all ? If it is the conflicting accesses are > triggered by the Ada implementation, I can add them to the default drd > suppression file. I've just discovered that the suppression I sent is almost useless, since whether it works or not depends strongly on the compiler version, i.e. while it works for me it most likely will not work for anyone else on the planet... I can try to generate multiple suppressions that cover all known compiler versions, but I'd rather not do that right now. Ciao, Duncan. |
|
From: Duncan S. <bal...@fr...> - 2007-01-02 13:50:19
|
On Tuesday 2 January 2007 13:59, Bart Van Assche wrote: > On 1/1/07, Duncan Sands <bal...@fr...> wrote: > > Hi Bart, > > > > > A new drd version is available at > > > http://home.euphonynet.be/bvassche/valgrind/valgrind-6458-drd-2006-12-30.patch.gz. > > > > thanks for doing this. I gave it a whirl and it seems to work fine. However it > > reported a false positive: two threads, thread 1 and thread 2, write to the same > > memory location in an unsynchronized way, but they write *the same value* to it. > > Thread 1 then reads the value, which may have last been written by thread 1 or > > thread 2. This gets reported as a race, even though there is no race since the > > value read is independent of the order in which the threads wrote it: > > It wouldn't be easy to recognize this pattern in the drd tool. Drat. > Is it > possible to generate a suppression pattern with Valgrind's option > --gen-suppressions=all ? If it is the conflicting accesses are > triggered by the Ada implementation, I can add them to the default drd > suppression file. It is indeed in the Ada implementation. The following seems to work: --- default.supp 2007-01-02 14:18:33.000000000 +0100 +++ /usr/local/lib/valgrind/drd/default.supp 2007-01-02 14:42:49.000000000 +0100 @@ -188,3 +188,10 @@ drd:ConflictingAccess fun:_pthread_cleanup_push_defer } +{ + gnat@create_task + drd:ConflictingAccess + fun:system__task_primitives__operations__set_priority + fun:system__task_primitives__operations__create_task + fun:system__tasking__stages__activate_tasks +} Best wishes, Duncan. |
|
From: Bart V. A. <bar...@gm...> - 2007-01-02 13:00:01
|
On 1/1/07, Duncan Sands <bal...@fr...> wrote: > Hi Bart, > > > A new drd version is available at > > http://home.euphonynet.be/bvassche/valgrind/valgrind-6458-drd-2006-12-30.patch.gz. > > thanks for doing this. I gave it a whirl and it seems to work fine. However it > reported a false positive: two threads, thread 1 and thread 2, write to the same > memory location in an unsynchronized way, but they write *the same value* to it. > Thread 1 then reads the value, which may have last been written by thread 1 or > thread 2. This gets reported as a race, even though there is no race since the > value read is independent of the order in which the threads wrote it: It wouldn't be easy to recognize this pattern in the drd tool. Is it possible to generate a suppression pattern with Valgrind's option --gen-suppressions=all ? If it is the conflicting accesses are triggered by the Ada implementation, I can add them to the default drd suppression file. Bart. |
|
From: Bart V. A. <bar...@gm...> - 2007-01-02 11:03:10
|
A new drd version is available at the following location: http://home.euphonynet.be/bvassche/valgrind/valgrind-6472-drd-2007-01-02.patch.gz Changes since version 2006-12-30: - Code in the .plt section is no longer instrumented, such that accesses to the .got.plt section are no longer considered as races. - Cleaned up the suppression file drd/default.supp. - The suppression file drd/default.supp is now loaded by default. New bugs: - The suppression file drd/default.supp has to be installed manually, this does not happen yet automatically via 'make install'. Bart. |
|
From: Duncan S. <bal...@fr...> - 2007-01-02 10:52:18
|
Hi Bart, > A new drd version is available at > http://home.euphonynet.be/bvassche/valgrind/valgrind-6458-drd-2006-12-30.patch.gz. thanks for doing this. I gave it a whirl and it seems to work fine. However it reported a false positive: two threads, thread 1 and thread 2, write to the same memory location in an unsynchronized way, but they write *the same value* to it. Thread 1 then reads the value, which may have last been written by thread 1 or thread 2. This gets reported as a race, even though there is no race since the value read is independent of the order in which the threads wrote it: ==5219== Conflicting load by thread 1 at 0x04413398 size 4 ==5219== at 0x8075A40: system__task_primitives__operations__set_priority (s-taprop.adb:627) <= reads the value ==5219== by 0x8075C8B: system__task_primitives__operations__create_task (s-taprop.adb:787) <= wrote the value ==5219== by 0x80EA0BB: system__tasking__stages__activate_tasks (s-tassta.adb:344) ==5219== by 0x82287DF: notification_support__dispatch___elabb (notification_support-dispatch.adb:5) ==5219== by 0x804C256: adainit (b~smkr.adb:825) ==5219== by 0x804D4A2: main (b~smkr.adb:1619) ==5219== Allocation context: heap, offset 64 in block at 0x4413358 of size 1888 ==5219== at 0x4020516: malloc (vg_replace_malloc.c:207) ==5219== by 0x8073D5F: __gnat_malloc (s-memory.adb:92) ==5219== by 0x8075AF3: system__task_primitives__operations__new_atcb (s-taprop.adb:672) ==5219== by 0x80EA46E: system__tasking__stages__create_task (s-tassta.adb:563) ==5219== by 0x82275EB: notification_support__dispatch__message_taskTKVIP (notification_support-dispatch.adb:55) ==5219== by 0x82287CC: notification_support__dispatch___elabb (notification_support-dispatch.adb:73) ==5219== by 0x804C256: adainit (b~smkr.adb:825) ==5219== by 0x804D4A2: main (b~smkr.adb:1619) ==5219== Other segment start (thread 2) ==5219== at 0x433D3D8: clone (in /lib/tls/i686/cmov/libc-2.5.so) <= writes the value ==5219== Other segment end (thread 2) ==5219== at 0x40007F2: (within /lib/ld-2.5.so) ==5219== by 0x4022720: pthread_mutex_lock (drd_preloaded.c:284) ==5219== by 0x8075511: system__task_primitives__operations__write_lock__2 (s-taprop.adb:333) ==5219== by 0x80753DE: system__task_primitives__operations__lock_rts (s-taprop.adb:209) ==5219== by 0x8075A7C: system__task_primitives__operations__enter_task (s-taprop.adb:653) ==5219== by 0x80EAD08: system__tasking__stages__task_wrapper (s-tassta.adb:1006) ==5219== by 0x402214F: vg_thread_wrapper (drd_preloaded.c:133) ==5219== by 0x425131A: start_thread (in /lib/tls/i686/cmov/libpthread-2.5.so) ==5219== by 0x433D3ED: clone (in /lib/tls/i686/cmov/libc-2.5.so) The context is this: the value in question is the pthread_t thread id of the newly created thread. Both the parent and child need it. The parent gets the value from pthread_create, the child gets it from pthread_self. Once obtained, each of them writes it to a data structure shared between them, memory location 0x04413398 in the above example. After storing the thread id, parent and child call various functions that use it, reading the thread id from the shared data structure; for example system__task_primitives__operations__set_priority reads it (the read reported above). Any thoughts on this? Thanks again and best wishes, Duncan. |
|
From: Bart V. A. <bar...@gm...> - 2007-01-02 08:36:31
|
Apparently the byte size of the source tree increased, so I started looking for the largest files. I found some large files whose purpose is unknown to me ? $ find -type f -ls | grep -v '/\.svn/' | sort -n +6 ... 1101167 853 -rw-r--r-- 1 bart users 869782 Jan 2 10:18 ./branch32/VEX/orig_x86/fpu_mmx_sse.orig 1101200 1133 -rw-r--r-- 1 bart users 1156810 Jan 2 10:18 ./branch32/VEX/orig_ppc32/loadsafp.orig 1101202 1481 -rw-r--r-- 1 bart users 1511720 Jan 2 10:18 ./branch32/VEX/orig_ppc32/return0.orig 1101201 3367 -rw-r--r-- 1 bart users 3443743 Jan 2 10:18 ./branch32/VEX/orig_ppc32/date.orig Bart. |