You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(122) |
Nov
(152) |
Dec
(69) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
(6) |
Feb
(25) |
Mar
(73) |
Apr
(82) |
May
(24) |
Jun
(25) |
Jul
(10) |
Aug
(11) |
Sep
(10) |
Oct
(54) |
Nov
(203) |
Dec
(182) |
| 2004 |
Jan
(307) |
Feb
(305) |
Mar
(430) |
Apr
(312) |
May
(187) |
Jun
(342) |
Jul
(487) |
Aug
(637) |
Sep
(336) |
Oct
(373) |
Nov
(441) |
Dec
(210) |
| 2005 |
Jan
(385) |
Feb
(480) |
Mar
(636) |
Apr
(544) |
May
(679) |
Jun
(625) |
Jul
(810) |
Aug
(838) |
Sep
(634) |
Oct
(521) |
Nov
(965) |
Dec
(543) |
| 2006 |
Jan
(494) |
Feb
(431) |
Mar
(546) |
Apr
(411) |
May
(406) |
Jun
(322) |
Jul
(256) |
Aug
(401) |
Sep
(345) |
Oct
(542) |
Nov
(308) |
Dec
(481) |
| 2007 |
Jan
(427) |
Feb
(326) |
Mar
(367) |
Apr
(255) |
May
(244) |
Jun
(204) |
Jul
(223) |
Aug
(231) |
Sep
(354) |
Oct
(374) |
Nov
(497) |
Dec
(362) |
| 2008 |
Jan
(322) |
Feb
(482) |
Mar
(658) |
Apr
(422) |
May
(476) |
Jun
(396) |
Jul
(455) |
Aug
(267) |
Sep
(280) |
Oct
(253) |
Nov
(232) |
Dec
(304) |
| 2009 |
Jan
(486) |
Feb
(470) |
Mar
(458) |
Apr
(423) |
May
(696) |
Jun
(461) |
Jul
(551) |
Aug
(575) |
Sep
(134) |
Oct
(110) |
Nov
(157) |
Dec
(102) |
| 2010 |
Jan
(226) |
Feb
(86) |
Mar
(147) |
Apr
(117) |
May
(107) |
Jun
(203) |
Jul
(193) |
Aug
(238) |
Sep
(300) |
Oct
(246) |
Nov
(23) |
Dec
(75) |
| 2011 |
Jan
(133) |
Feb
(195) |
Mar
(315) |
Apr
(200) |
May
(267) |
Jun
(293) |
Jul
(353) |
Aug
(237) |
Sep
(278) |
Oct
(611) |
Nov
(274) |
Dec
(260) |
| 2012 |
Jan
(303) |
Feb
(391) |
Mar
(417) |
Apr
(441) |
May
(488) |
Jun
(655) |
Jul
(590) |
Aug
(610) |
Sep
(526) |
Oct
(478) |
Nov
(359) |
Dec
(372) |
| 2013 |
Jan
(467) |
Feb
(226) |
Mar
(391) |
Apr
(281) |
May
(299) |
Jun
(252) |
Jul
(311) |
Aug
(352) |
Sep
(481) |
Oct
(571) |
Nov
(222) |
Dec
(231) |
| 2014 |
Jan
(185) |
Feb
(329) |
Mar
(245) |
Apr
(238) |
May
(281) |
Jun
(399) |
Jul
(382) |
Aug
(500) |
Sep
(579) |
Oct
(435) |
Nov
(487) |
Dec
(256) |
| 2015 |
Jan
(338) |
Feb
(357) |
Mar
(330) |
Apr
(294) |
May
(191) |
Jun
(108) |
Jul
(142) |
Aug
(261) |
Sep
(190) |
Oct
(54) |
Nov
(83) |
Dec
(22) |
| 2016 |
Jan
(49) |
Feb
(89) |
Mar
(33) |
Apr
(50) |
May
(27) |
Jun
(34) |
Jul
(53) |
Aug
(53) |
Sep
(98) |
Oct
(206) |
Nov
(93) |
Dec
(53) |
| 2017 |
Jan
(65) |
Feb
(82) |
Mar
(102) |
Apr
(86) |
May
(187) |
Jun
(67) |
Jul
(23) |
Aug
(93) |
Sep
(65) |
Oct
(45) |
Nov
(35) |
Dec
(17) |
| 2018 |
Jan
(26) |
Feb
(35) |
Mar
(38) |
Apr
(32) |
May
(8) |
Jun
(43) |
Jul
(27) |
Aug
(30) |
Sep
(43) |
Oct
(42) |
Nov
(38) |
Dec
(67) |
| 2019 |
Jan
(32) |
Feb
(37) |
Mar
(53) |
Apr
(64) |
May
(49) |
Jun
(18) |
Jul
(14) |
Aug
(53) |
Sep
(25) |
Oct
(30) |
Nov
(49) |
Dec
(31) |
| 2020 |
Jan
(87) |
Feb
(45) |
Mar
(37) |
Apr
(51) |
May
(99) |
Jun
(36) |
Jul
(11) |
Aug
(14) |
Sep
(20) |
Oct
(24) |
Nov
(40) |
Dec
(23) |
| 2021 |
Jan
(14) |
Feb
(53) |
Mar
(85) |
Apr
(15) |
May
(19) |
Jun
(3) |
Jul
(14) |
Aug
(1) |
Sep
(57) |
Oct
(73) |
Nov
(56) |
Dec
(22) |
| 2022 |
Jan
(3) |
Feb
(22) |
Mar
(6) |
Apr
(55) |
May
(46) |
Jun
(39) |
Jul
(15) |
Aug
(9) |
Sep
(11) |
Oct
(34) |
Nov
(20) |
Dec
(36) |
| 2023 |
Jan
(79) |
Feb
(41) |
Mar
(99) |
Apr
(169) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(57) |
Sep
(19) |
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
|
|
|
1
(17) |
2
(11) |
3
(6) |
4
(6) |
|
5
(10) |
6
(5) |
7
(3) |
8
(7) |
9
(4) |
10
(4) |
11
(3) |
|
12
(3) |
13
(17) |
14
(18) |
15
(32) |
16
(22) |
17
(18) |
18
(10) |
|
19
(4) |
20
(3) |
21
(8) |
22
(15) |
23
(32) |
24
(28) |
25
(18) |
|
26
(20) |
27
(16) |
28
(28) |
29
(28) |
30
(27) |
|
|
|
From: Nicholas N. <n.n...@gm...> - 2009-04-13 22:14:40
|
On Mon, Apr 13, 2009 at 10:06 PM, Konstantin Serebryany > > Add http://software.intel.com/en-us/intel-parallel-studio-home/ to this list. > A PIN-based hybrid of Memcheck and Helgrind, works on windows. Beta is free. On the Memcheck side, it looks like it's just a leak detector. Nick |
|
From: Tor L. <tm...@ik...> - 2009-04-13 13:44:38
|
> Beta is free. The first hit is free. That is a well-known and successful business model! --tml |
|
From: Konstantin S. <kon...@gm...> - 2009-04-13 12:06:43
|
On Mon, Apr 13, 2009 at 3:31 PM, Tor Lillqvist <tm...@ik...> wrote: >> Thanks for your help, I think program running under Windows (such as .NET >> program) often need to be tainted for further program analysis or bug >> detection. > > I think you are misguided here when generalizing .NET applications and > traditional Windows applications. After all, .NET applications (as > long as we are talking about ones that contain only managed code and > not tons of unsafe (native) code) are safe, by definition, from many > types of errors. Just like Java code. > >> Unfortunately, I find little binary-level instrumented tools >> which can achieves the goal. Is there anybody knows it? > > BoundsChecker, Purify, etc. Add http://software.intel.com/en-us/intel-parallel-studio-home/ to this list. A PIN-based hybrid of Memcheck and Helgrind, works on windows. Beta is free. --kcc > There are lots of tools. They cost money, > though, but many of them are worth their price. (And many, presumably, > nowadays also support .NET, although surely internally the mechanisms > they use for that are very different from the ones used for > traditional machine code). > >> BTW, CIL is a very efficient and robust tools for instrumenting the program >> with source code available. > > Huh? CIL is not a tool, it means "Common Intermediate Language", i.e. > it is the "bytecode" that managed .NET assemblies consist of. > (Apparently the term "CIL" can mean either the actual binary bytecode, > or its (one-to-one) "human-readable" textual representation, which I > find a bit confusing. Or maybe I misunderstand something.) > >> But it seems that it can not instrument the binary code, right? > > What "it"? And what "binary code", the .NET CIL "bytecode" or x86 machine code? > > Obviously very different tools are used to manipulate CIL and machine > code. To inspect and instrument CIL code one would most naturally > write such a tool in .NET itself and use functionality provided by > classes in the System.Reflection and System.Reflection.Emit > namespaces. To instrument machine code, something like Valgrind, > Purify, Dynamo/RIO etc would be used. > > --tml > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > High Quality Requirements in a Collaborative Environment. > Download a free trial of Rational Requirements Composer Now! > http://p.sf.net/sfu/www-ibm-com > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers > |
|
From: Bart V. A. <bar...@gm...> - 2009-04-13 11:37:06
|
2009/4/13 chenping19850429 <che...@16...>: > I want to instrument the .NET program. I find Valgrind can only run in > Linux. > Anyone knows if there any Valgrind like tool on Windows, which can > instrument the .NET program? It would help if you could tell us why you want to instrument .NET programs at the binary level, Do you want to analyze .NET programs with one of the existing Valgrind tools, or do you want to develop a new Valgrind tool yourself ? Bart. |
|
From: Tor L. <tm...@ik...> - 2009-04-13 11:31:30
|
> Thanks for your help, I think program running under Windows (such as .NET > program) often need to be tainted for further program analysis or bug > detection. I think you are misguided here when generalizing .NET applications and traditional Windows applications. After all, .NET applications (as long as we are talking about ones that contain only managed code and not tons of unsafe (native) code) are safe, by definition, from many types of errors. Just like Java code. > Unfortunately, I find little binary-level instrumented tools > which can achieves the goal. Is there anybody knows it? BoundsChecker, Purify, etc. There are lots of tools. They cost money, though, but many of them are worth their price. (And many, presumably, nowadays also support .NET, although surely internally the mechanisms they use for that are very different from the ones used for traditional machine code). > BTW, CIL is a very efficient and robust tools for instrumenting the program > with source code available. Huh? CIL is not a tool, it means "Common Intermediate Language", i.e. it is the "bytecode" that managed .NET assemblies consist of. (Apparently the term "CIL" can mean either the actual binary bytecode, or its (one-to-one) "human-readable" textual representation, which I find a bit confusing. Or maybe I misunderstand something.) > But it seems that it can not instrument the binary code, right? What "it"? And what "binary code", the .NET CIL "bytecode" or x86 machine code? Obviously very different tools are used to manipulate CIL and machine code. To inspect and instrument CIL code one would most naturally write such a tool in .NET itself and use functionality provided by classes in the System.Reflection and System.Reflection.Emit namespaces. To instrument machine code, something like Valgrind, Purify, Dynamo/RIO etc would be used. --tml |
|
From: chenping19850429 <che...@16...> - 2009-04-13 11:10:12
|
Thanks for your help, I think program running under Windows (such as .NET program) often need to be tainted for further program analysis or bug detection. Unfortunately, I find little binary-level instrumented tools which can achieves the goal. Is there anybody knows it? BTW, CIL is a very efficient and robust tools for instrumenting the program with source code available. But it seems that it can not instrument the binary code, right? Thanks. Ping Chen 在2009-04-13,"Tor Lillqvist" <tm...@ik...> 写道: >> ??? I want to instrument the .NET program. > >What do you mean with "the" .NET program? The Microsoft .NET Framework >CLR implementation, i.e. their virtual machine that runs .NET >programs? > >Or just *a* .NET program, i.e. presumably some C# (or other .NET >language) code you have written yourself? I assume that is what you >mean. > >In a managed environment with garbage collection, I can't really see >much need for a tool like memcheck, for instance, as there by >definition can be no buffer overruns, no access to "freed" memory, and >no undefined memory. That doesn't mean that instrumentation wouldn't >be useful for other kinds of tools, like tracking large objects that >references are kept to but never used, i.e. effectively "leaks". > >> Anyone knows if there any Valgrind like tool on Windows, which can >> instrument the .NET program? > >Try googling for relevant keywords like "instrumenting", "managed", >".net", "assemblies." You are not likely to see many experts in this >area on this list I think.. > >As such, instrumenting .net assemblies is probably rather easy, given >that it is well-documented virtual machine bytecode (CIL) that one >would be instrumenting, and there (presumably) are nice class >libraries built in that can be used to load the CIL from assemblies, >modify that CIL, construct new assemblies dynamically, etc. (My >terminology is probably off here, sorry.) > >I assume a tool that does such instrumentation would be >platform-independent unless written carelessly, i.e. it could be used >as well on Windows (running under the MS .NET Framework), or on some >Unix running under Mono. It would have very little in common with what >Valgrind does, except from a very high-level executive summary point >of view. > >--tml |
|
From: Tor L. <tm...@ik...> - 2009-04-13 09:46:08
|
> It has already been considered to port Valgrind to Windows, but as far > as I know nobody is working on a port of Valgrind for Windows. I am, "in my copious spare time" (well, the ongoing Easter holidays has offered some nice hacking time, with the wife having to work and the daughter visiting her cousin;). It's not at the stage yet where it would be useful to offer diffs so interested parties could help the effort, sorry, as there will presumably be much rework of design decisions from scratch, or maybe I'll even end up abandoning up the attempt. But it compiles (with lots of stuff ifdeffed out, of course), and in some months or a year, I might have something vaguely useful. --tml |
|
From: Tor L. <tm...@ik...> - 2009-04-13 09:35:02
|
> I want to instrument the .NET program. What do you mean with "the" .NET program? The Microsoft .NET Framework CLR implementation, i.e. their virtual machine that runs .NET programs? Or just *a* .NET program, i.e. presumably some C# (or other .NET language) code you have written yourself? I assume that is what you mean. In a managed environment with garbage collection, I can't really see much need for a tool like memcheck, for instance, as there by definition can be no buffer overruns, no access to "freed" memory, and no undefined memory. That doesn't mean that instrumentation wouldn't be useful for other kinds of tools, like tracking large objects that references are kept to but never used, i.e. effectively "leaks". > Anyone knows if there any Valgrind like tool on Windows, which can > instrument the .NET program? Try googling for relevant keywords like "instrumenting", "managed", ".net", "assemblies." You are not likely to see many experts in this area on this list I think.. As such, instrumenting .net assemblies is probably rather easy, given that it is well-documented virtual machine bytecode (CIL) that one would be instrumenting, and there (presumably) are nice class libraries built in that can be used to load the CIL from assemblies, modify that CIL, construct new assemblies dynamically, etc. (My terminology is probably off here, sorry.) I assume a tool that does such instrumentation would be platform-independent unless written carelessly, i.e. it could be used as well on Windows (running under the MS .NET Framework), or on some Unix running under Mono. It would have very little in common with what Valgrind does, except from a very high-level executive summary point of view. --tml |
|
From: Bart V. A. <bar...@gm...> - 2009-04-13 09:21:40
|
2009/4/13 chenping19850429 <che...@16...>: > I want to instrument the .NET program. I find Valgrind can only run in > Linux. > Anyone knows if there any Valgrind like tool on Windows, which can > instrument the .NET program? It has already been considered to port Valgrind to Windows, but as far as I know nobody is working on a port of Valgrind for Windows. Have you already considered to run your .NET program under Mono on a Linux system ? Bart. |
|
From: chenping19850429 <che...@16...> - 2009-04-13 09:09:16
|
Hi all,
I want to instrument the .NET program. I find Valgrind can only run in Linux.
Anyone knows if there any Valgrind like tool on Windows, which can instrument the .NET program?
Thanks.
Ping Chen
|
|
From: Konstantin S. <kon...@gm...> - 2009-04-13 08:53:07
|
On Mon, Apr 13, 2009 at 12:22 PM, Bart Van Assche <bar...@gm...> wrote: > On Mon, Mar 30, 2009 at 8:40 PM, Konstantin Serebryany > <kon...@gm...> wrote: >> [changed subject] >> >> On Mon, Mar 30, 2009 at 2:10 PM, Bart Van Assche >> <bar...@gm...> wrote: >>> On Mon, Mar 30, 2009 at 4:53 PM, Konstantin Serebryany >>> <kon...@gm...> wrote: >>>>> Did you check whether DRD reports a false positive on your TLS test case ? >>>> >>>> DRD says nothing about TLS in this test (it prints lots of reports >>>> about _dl_lookup_symbol_x though) >>> >>> On which distro did this occur ? >> >> We have (a slightly modified) Ubuntu Hardy Heron LTS (8.04). >> >>> The following command does not >>> complain about _dl_lookup_symbol_x on Ubuntu 7.10 nor on openSUSE >>> 11.1: >>> >>> ./vg-in-place --tool=drd --check-stack-var=yes >>> drt/unittest/racecheck_unittest 130 >> >> using recent trunk: >> % ./vg-in-place --tool=drd --check-stack-var=yes >> ~/drt/trunk/unittest/racecheck_unittest 130 >> ==6335== Conflicting load by thread 1/1 at 0x0cb363a8 size 8 >> ==6335== at 0xC927332: _dl_lookup_symbol_x (in >> /usr/grte/v1/lib64/ld-2.3.6.so) >> ==6335== by 0xC92AB31: fixup (in /usr/grte/v1/lib64/ld-2.3.6.so) >> ==6335== by 0xC92A861: _dl_runtime_resolve (in >> /usr/grte/v1/lib64/ld-2.3.6.so) >> ==6335== by 0x41EB38: MyThreadArray::Start() (racecheck_unittest.cc:267) >> ==6335== by 0x40CB3C: test130::Run() (racecheck_unittest.cc:6059) >> ==6335== by 0x41F104: Test::Run() (racecheck_unittest.cc:161) >> ==6335== by 0x41616C: main (racecheck_unittest.cc:230) >> ... <more> >> >> the file default.supp does not seem to have anything relevant. >> In tsan I simply ignore everything inside ld-*.so. Helps with performance too. > > Are you sure this also occurs on a stock Ubuntu 8.04 ? I am not sure. :( We have our own libraries, which are not understood by default.supp. The stock Ubuntu 8.04 might be alright. --kcc > I can't > reproduce the above behavior with neither the 32-bit nor the 64-bit > version of Ubuntu 8.04: > > ==7481== drd, a thread error detector. > ==7481== Copyright (C) 2006-2009, and GNU GPL'd, by Bart Van Assche. > ==7481== Using LibVEX rev 1888, a library for dynamic binary translation. > ==7481== Copyright (C) 2004-2009, and GNU GPL'd, by OpenWorks LLP. > ==7481== Using valgrind-3.5.0.SVN, a dynamic binary instrumentation framework. > ==7481== Copyright (C) 2000-2009, and GNU GPL'd, by Julian Seward et al. > ==7481== For more details, rerun with: -v > ==7481== > test130: Per-thread > per_thread_global=0 > ==7481== > ==7481== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 23 from 2) > > Between the time you observed the false positive and the time I ran > the above test a DRD-specific Qt4-suppression pattern and a > glib-specific suppression pattern have been generalized, but that > shouldn't have any influence on the behavior you reported. > > Bart. > |
|
From: Bart V. A. <bar...@gm...> - 2009-04-13 08:22:55
|
On Mon, Mar 30, 2009 at 8:40 PM, Konstantin Serebryany
<kon...@gm...> wrote:
> [changed subject]
>
> On Mon, Mar 30, 2009 at 2:10 PM, Bart Van Assche
> <bar...@gm...> wrote:
>> On Mon, Mar 30, 2009 at 4:53 PM, Konstantin Serebryany
>> <kon...@gm...> wrote:
>>>> Did you check whether DRD reports a false positive on your TLS test case ?
>>>
>>> DRD says nothing about TLS in this test (it prints lots of reports
>>> about _dl_lookup_symbol_x though)
>>
>> On which distro did this occur ?
>
> We have (a slightly modified) Ubuntu Hardy Heron LTS (8.04).
>
>> The following command does not
>> complain about _dl_lookup_symbol_x on Ubuntu 7.10 nor on openSUSE
>> 11.1:
>>
>> ./vg-in-place --tool=drd --check-stack-var=yes
>> drt/unittest/racecheck_unittest 130
>
> using recent trunk:
> % ./vg-in-place --tool=drd --check-stack-var=yes
> ~/drt/trunk/unittest/racecheck_unittest 130
> ==6335== Conflicting load by thread 1/1 at 0x0cb363a8 size 8
> ==6335== at 0xC927332: _dl_lookup_symbol_x (in
> /usr/grte/v1/lib64/ld-2.3.6.so)
> ==6335== by 0xC92AB31: fixup (in /usr/grte/v1/lib64/ld-2.3.6.so)
> ==6335== by 0xC92A861: _dl_runtime_resolve (in
> /usr/grte/v1/lib64/ld-2.3.6.so)
> ==6335== by 0x41EB38: MyThreadArray::Start() (racecheck_unittest.cc:267)
> ==6335== by 0x40CB3C: test130::Run() (racecheck_unittest.cc:6059)
> ==6335== by 0x41F104: Test::Run() (racecheck_unittest.cc:161)
> ==6335== by 0x41616C: main (racecheck_unittest.cc:230)
> ... <more>
>
> the file default.supp does not seem to have anything relevant.
> In tsan I simply ignore everything inside ld-*.so. Helps with performance too.
Are you sure this also occurs on a stock Ubuntu 8.04 ? I can't
reproduce the above behavior with neither the 32-bit nor the 64-bit
version of Ubuntu 8.04:
==7481== drd, a thread error detector.
==7481== Copyright (C) 2006-2009, and GNU GPL'd, by Bart Van Assche.
==7481== Using LibVEX rev 1888, a library for dynamic binary translation.
==7481== Copyright (C) 2004-2009, and GNU GPL'd, by OpenWorks LLP.
==7481== Using valgrind-3.5.0.SVN, a dynamic binary instrumentation framework.
==7481== Copyright (C) 2000-2009, and GNU GPL'd, by Julian Seward et al.
==7481== For more details, rerun with: -v
==7481==
test130: Per-thread
per_thread_global=0
==7481==
==7481== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 23 from 2)
Between the time you observed the false positive and the time I ran
the above test a DRD-specific Qt4-suppression pattern and a
glib-specific suppression pattern have been generalized, but that
shouldn't have any influence on the behavior you reported.
Bart.
|
|
From: <sv...@va...> - 2009-04-13 08:21:55
|
Author: bart
Date: 2009-04-13 09:21:47 +0100 (Mon, 13 Apr 2009)
New Revision: 9522
Log:
Another suppression pattern generalization.
Modified:
trunk/glibc-2.X-drd.supp
Modified: trunk/glibc-2.X-drd.supp
===================================================================
--- trunk/glibc-2.X-drd.supp 2009-04-13 08:05:18 UTC (rev 9521)
+++ trunk/glibc-2.X-drd.supp 2009-04-13 08:21:47 UTC (rev 9522)
@@ -314,7 +314,6 @@
libglib-g_get_language_names
drd:ConflictingAccess
fun:g_slice_free_chain_with_offset
- fun:g_get_language_names
}
{
libQtCore-deref-that-calls-QThreadData-destructor
|
|
From: Bart V. A. <bar...@gm...> - 2009-04-13 08:20:47
|
Nightly build on georgia-tech-cellbuzz-native ( cellbuzz, ppc64, Fedora 7, native ) started at 2009-04-13 02:00:05 EDT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... done Regression test results follow == 407 tests, 36 stderr failures, 9 stdout failures, 0 post failures == exp-ptrcheck/tests/bad_percentify (stderr) exp-ptrcheck/tests/base (stderr) exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/fp (stderr) exp-ptrcheck/tests/globalerr (stderr) exp-ptrcheck/tests/hackedbz2 (stderr) exp-ptrcheck/tests/hp_bounds (stderr) exp-ptrcheck/tests/hp_dangle (stderr) exp-ptrcheck/tests/justify (stderr) exp-ptrcheck/tests/partial_bad (stderr) exp-ptrcheck/tests/partial_good (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) exp-ptrcheck/tests/realloc (stderr) exp-ptrcheck/tests/stackerr (stderr) exp-ptrcheck/tests/strcpy (stderr) exp-ptrcheck/tests/supp (stderr) exp-ptrcheck/tests/tricky (stderr) exp-ptrcheck/tests/unaligned (stderr) exp-ptrcheck/tests/zero (stderr) helgrind/tests/hg05_race2 (stderr) memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cases-full (stderr) memcheck/tests/leak-cases-summary (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/origin5-bz2 (stderr) memcheck/tests/varinfo1 (stderr) memcheck/tests/varinfo2 (stderr) memcheck/tests/varinfo3 (stderr) memcheck/tests/varinfo4 (stderr) memcheck/tests/varinfo5 (stderr) memcheck/tests/varinfo6 (stderr) memcheck/tests/wrap8 (stderr) none/tests/linux/mremap (stderr) none/tests/linux/mremap2 (stdout) none/tests/ppc32/jm-fp (stdout) none/tests/ppc32/jm-vmx (stdout) none/tests/ppc32/round (stdout) none/tests/ppc32/test_gx (stdout) none/tests/ppc64/jm-fp (stdout) none/tests/ppc64/jm-vmx (stdout) none/tests/ppc64/round (stdout) none/tests/shell_valid2 (stderr) none/tests/shell_valid3 (stderr) |
|
From: <sv...@va...> - 2009-04-13 08:05:24
|
Author: bart
Date: 2009-04-13 09:05:18 +0100 (Mon, 13 Apr 2009)
New Revision: 9521
Log:
Make sure that DRD does not complain about mutexes being held too long on systems where the clock can go backward. Apparently this happens frequently when Linux is running inside a virtual machine.
Modified:
trunk/drd/drd_mutex.c
trunk/drd/drd_rwlock.c
Modified: trunk/drd/drd_mutex.c
===================================================================
--- trunk/drd/drd_mutex.c 2009-04-08 15:06:34 UTC (rev 9520)
+++ trunk/drd/drd_mutex.c 2009-04-13 08:05:18 UTC (rev 9521)
@@ -405,7 +405,7 @@
{
if (s_mutex_lock_threshold_ms > 0)
{
- ULong held = VG_(read_millisecond_timer)() - p->acquiry_time_ms;
+ Long held = VG_(read_millisecond_timer)() - p->acquiry_time_ms;
if (held > s_mutex_lock_threshold_ms)
{
HoldtimeErrInfo HEI
Modified: trunk/drd/drd_rwlock.c
===================================================================
--- trunk/drd/drd_rwlock.c 2009-04-08 15:06:34 UTC (rev 9520)
+++ trunk/drd/drd_rwlock.c 2009-04-13 08:05:18 UTC (rev 9521)
@@ -521,7 +521,7 @@
q->reader_nesting_count--;
if (q->reader_nesting_count == 0 && DRD_(s_shared_threshold_ms) > 0)
{
- ULong held = VG_(read_millisecond_timer)() - p->acquiry_time_ms;
+ Long held = VG_(read_millisecond_timer)() - p->acquiry_time_ms;
if (held > DRD_(s_shared_threshold_ms))
{
HoldtimeErrInfo HEI
@@ -539,7 +539,7 @@
q->writer_nesting_count--;
if (q->writer_nesting_count == 0 && DRD_(s_exclusive_threshold_ms) > 0)
{
- ULong held = VG_(read_millisecond_timer)() - p->acquiry_time_ms;
+ Long held = VG_(read_millisecond_timer)() - p->acquiry_time_ms;
if (held > DRD_(s_exclusive_threshold_ms))
{
HoldtimeErrInfo HEI
|
|
From: Tom H. <th...@cy...> - 2009-04-13 03:03:35
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2009-04-13 03:05:06 BST 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 == 478 tests, 4 stderr failures, 0 stdout failures, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) |
|
From: Tom H. <th...@cy...> - 2009-04-13 02:47:29
|
Nightly build on mg ( x86_64, Fedora 9 ) started at 2009-04-13 03:10:05 BST 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 == 484 tests, 4 stderr failures, 1 stdout failure, 0 post failures == exp-ptrcheck/tests/ccc (stderr) exp-ptrcheck/tests/preen_invars (stderr) exp-ptrcheck/tests/pth_create (stderr) exp-ptrcheck/tests/pth_specific (stderr) none/tests/linux/mremap2 (stdout) |