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
(11) |
2
(9) |
3
(14) |
4
(18) |
5
(13) |
|
6
(4) |
7
(12) |
8
(16) |
9
(14) |
10
(8) |
11
(9) |
12
(7) |
|
13
(12) |
14
(6) |
15
(14) |
16
(5) |
17
(10) |
18
(8) |
19
(5) |
|
20
(10) |
21
(16) |
22
(5) |
23
(14) |
24
(10) |
25
(11) |
26
(6) |
|
27
(9) |
28
(8) |
29
(11) |
30
(9) |
31
(18) |
|
|
|
From: Nicholas N. <nj...@cs...> - 2008-01-31 23:21:28
|
On Thu, 31 Jan 2008, Bart Van Assche wrote: > On Jan 29, 2008 10:36 PM, <sv...@va...> wrote: >> --- trunk/docs/internals/3_3_BUGSTATUS.txt 2008-01-29 21:35:25 UTC (rev 7362) >> +++ trunk/docs/internals/3_3_BUGSTATUS.txt 2008-01-29 21:36:47 UTC (rev 7363) >> @@ -27,3 +27,5 @@ >> >> r7355 7356 33 155929 ms_print fails on massif outputs >> containing long lines >> + >> +r7361 7362 33 n-i-bz ms_print broken for --time-unit=ms > > What are the criteria for adding a bug to this list ? I recently > logged http://bugs.kde.org/show_bug.cgi?id=156404, but as far as I > know this issue is not yet in the 3_3_BUGSTATUS.txt file. No fixed criteria, really. It's good to add to it when a bug is fixed, so it can be mentioned in the release notes. And it's good to add bugs that you intend to fix. Nick |
|
From: Julian S. <js...@ac...> - 2008-01-31 20:27:33
|
> > > Trying to run OpenOffice and Firefox on my machine leads to this. > > > > > > --1052-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 > > > > (SIGSEGV) - > > > > > exiting > > > --1052-- si_code=1; Faulting address: 0x0; sp: 0x478CDF4 > > > > > > valgrind: the 'impossible' happened: > > > Killed by fatal signal > > > ==1052== at 0x3801979C: vgPlain_strlen (m_libcbase.c:232) > > > ==1052== by 0x38010941: evh__pre_mem_read_asciiz (hg_main.c:5763) > > > ==1052== by 0x38037D47: vgPlain_client_syscall (syswrap-main.c:850) > > > ==1052== by 0x38035899: vgPlain_scheduler (scheduler.c:790) > > > ==1052== by 0x38048C0D: run_a_thread_NORETURN (syswrap-linux.c:89) > > > > Hmm. I can't imagine how that happened. If you send a patch against > > the svn trunk, I can try to reproduce and chase the problem for you. > > This is unmodified version from svn trunk. Happens on both 32- and 64-bit. > Looks like a common issue on my system, some other programs (e.g. acroread) > fail as well. I can't reproduce it, using acroread on openSUSE 10.2 (64-bit) and --tool=memcheck or --tool=helgrind. Can you run with --trace-syscalls=yes and send the last few lines of the log? J |
|
From: Konstantin S. <kon...@gm...> - 2008-01-31 19:18:54
|
> > > I suspect most real-world threaded apps use both locks and HB stuff. Agree. But still the ratio between locks and HB could vary a lot. Also the users may have different preferences regarding false-positives vs false-nagatives and between speed and accuracy. > > Certainly. Right now it is ~60% slower than MSMHelgrind, but there are > > still things to improve there. > > I would say, first figure out if MSMProp1 is a SM that will work well > for you, in terms of false positive/negative behaviour. If yes then > there are probably many tricks to improve performance. It's hard. With slower machine more tests fail due to timeouts. So, without making the machine fast I can't really evaluate it. This is why I am so much interested in unit tests. > > > > Also with MSMProp1 I see less false positives on my apps. > > That sounds good, but I did not exactly understand .. you said above > that MSMProp1 reports ~30% more races. So are you saying that the 30% > more are real races that MSMHelgrind missed? Can you clarify? Sorry. The number of false positives *decreased slightly*, mostly due to correct handling of cond vars and barriers. The number of true positives *increased significantly*, mostly due to cases like test10. Overall number of reports increased with MSMProp1. This is more like an observation than a precise statistic. I am trying to collect real numbers and test cases. > > > > Trying to run OpenOffice and Firefox on my machine leads to this. > > > > --1052-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 > (SIGSEGV) - > > exiting > > --1052-- si_code=1; Faulting address: 0x0; sp: 0x478CDF4 > > > > valgrind: the 'impossible' happened: > > Killed by fatal signal > > ==1052== at 0x3801979C: vgPlain_strlen (m_libcbase.c:232) > > ==1052== by 0x38010941: evh__pre_mem_read_asciiz (hg_main.c:5763) > > ==1052== by 0x38037D47: vgPlain_client_syscall (syswrap-main.c:850) > > ==1052== by 0x38035899: vgPlain_scheduler (scheduler.c:790) > > ==1052== by 0x38048C0D: run_a_thread_NORETURN (syswrap-linux.c:89) > > Hmm. I can't imagine how that happened. If you send a patch against > the svn trunk, I can try to reproduce and chase the problem for you. This is unmodified version from svn trunk. Happens on both 32- and 64-bit. Looks like a common issue on my system, some other programs (e.g. acroread) fail as well. Is there anything I can do to help reproduce it? > > konqueror is not very threaded; I think this will not tell you anything > useful. > Yep, I see this already. :( |
|
From: Julian S. <js...@ac...> - 2008-01-31 18:43:04
|
> vex amd64->IR: unhandled instruction bytes: 0x48 0x8C 0xDB 0x48 0x48 0x8C is REX.W MOV Sw,Ev. This _might_ be valid but sounds unlikely. Can you re-run the program with -v -v and send the complete log? Only Valgrind's output is important; I don't care what the program prints out. J |
|
From: Konstantin S. <kon...@gm...> - 2008-01-31 18:05:51
|
Hi, While trying to run one of my tests under helgrind (unmodified valgrind 3.3.0 on x86_64) I've got the following message: vex amd64->IR: unhandled instruction bytes: 0x48 0x8C 0xDB 0x48 ==25817== valgrind: Unrecognised instruction at address 0x22CA8185. ==25817== Your program just tried to execute an instruction that Valgrind ==25817== did not recognise. There are two possible reasons for this. ==25817== 1. Your program has a bug and erroneously jumped to a non-code ==25817== location. If you are running Memcheck and you just saw a ==25817== warning about a bad jump, it's probably your program's fault. ==25817== 2. The instruction is legitimate but Valgrind doesn't handle it, ==25817== i.e. it's Valgrind's fault. If you think this is the case or ==25817== you are not sure, please let us know and we'll try to fix it. ==25817== Either way, Valgrind will now raise a SIGILL signal which will ==25817== probably kill your program. Surprisingly, it only happens under helgrind, memcheck works fine. I am not sure if this is 'Your program has a bug and erroneously jumped to a non-code' or 'The instruction is legitimate but Valgrind doesn't handle it'. Is there anything I could do to figure this out? --kcc |
|
From: Julian S. <js...@ac...> - 2008-01-31 13:10:27
|
> > I don't think you can have zero false positives and zero false > > negatives at the same time (holy grail ...), because all these state > > machines are different approximations to something which is NP-complete > > (and therefore which we cannot compute exactly). > > Oh, sure. > I think that it makes sense to have several different machines in helgrind > so that a user can choose one that fits his application best. > For example, if an application never creates/join threads (except for > startup/shutdown) and does not use semahpores, cond vars, message queues, > etc, Eraser will be enough. Using only locks, no semaphores, cond vars, MQs, no create/join, sounds unlikely to me :-) > If on contrary the application never use locks (but uses barriers, > semaphores, message queues, etc) locksets are useless. > The applications I try to analyze use both locks and HB stuff, so I need > both. I suspect most real-world threaded apps use both locks and HB stuff. > > Is it really needed? I don't know. But I don't know how to prove/argue > > that it is not needed. Alternative question is, is it possible to do > > this cheaply/incrementally? > > I thought about using unique lock id in locksets instead of Lock*. > It leads to a problem of mapping from the id to Lock* though... But we only > need this while reporting a race. Interesting possibility. > Yea... Perhaps we could garbage-collect old segments and if some SVal > still refers to a deleted one, behave conservatively. I think we can import some ideas from the world of garbage collection. Basically scan through shadow memory at a rate proportional to the rate of (simulated) instruction execution (rate may be selected adaptively). * some set S of segments are considered for deletion * once the scan starts, we guarantee to not create any more references to any segment in S * during the scan, if any SVal is seen to refer to an element of S, then that element is removed from S At the end of a scan, therefore, it is safe to delete the remaining segments in S. The scan then starts again. This makes it possible to recover memory from unreferenced segments at some constant cost per simulated instruction. Or something like that. > Certainly. Right now it is ~60% slower than MSMHelgrind, but there are > still things to improve there. I would say, first figure out if MSMProp1 is a SM that will work well for you, in terms of false positive/negative behaviour. If yes then there are probably many tricks to improve performance. > I've been trying both machines on some of my applications. MSMProp1 reports > ~30% more races. > Those extra races look similar to test10. Most (but not all!) of them look > harmless which makes me think about classifying data races somehow. > See e.g. http://www.eecs.umich.edu/~nsatish/DataRace-PLDI07.html. Yes. Also the Racetrack paper (Rodehoffer et al) has some useful ideas about classification. > Also with MSMProp1 I see less false positives on my apps. That sounds good, but I did not exactly understand .. you said above that MSMProp1 reports ~30% more races. So are you saying that the 30% more are real races that MSMHelgrind missed? Can you clarify? > Trying to run OpenOffice and Firefox on my machine leads to this. > > --1052-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - > exiting > --1052-- si_code=1; Faulting address: 0x0; sp: 0x478CDF4 > > valgrind: the 'impossible' happened: > Killed by fatal signal > ==1052== at 0x3801979C: vgPlain_strlen (m_libcbase.c:232) > ==1052== by 0x38010941: evh__pre_mem_read_asciiz (hg_main.c:5763) > ==1052== by 0x38037D47: vgPlain_client_syscall (syswrap-main.c:850) > ==1052== by 0x38035899: vgPlain_scheduler (scheduler.c:790) > ==1052== by 0x38048C0D: run_a_thread_NORETURN (syswrap-linux.c:89) Hmm. I can't imagine how that happened. If you send a patch against the svn trunk, I can try to reproduce and chase the problem for you. > I have better luck with konqueror, I'll try to compare the two machines on > it. konqueror is not very threaded; I think this will not tell you anything useful. J |
|
From: Ali J. <a.j...@gm...> - 2008-01-31 09:23:29
|
Hi Konstantin > And a quick question: does this machine handle barriers? I should with somemore examples . I justtest with some and it is working. > My I ask you to run all tests from racecheck_unittest (take the fresh version from <http://data-race-test.googlecode.com/svn/trunk/unittest/> http://data-race-test.googlecode.com/svn/trunk/unittest/) and send us the results? Also, if you have other tests that show difference between your machine and others, please shared those with us. Will you send me pls the file " thread_wrappers_pthread.h" so that I can run the test unit. Also there are some barriers example as I see. >> It is often possible for memory to change from Virgin ("New" is a better name, imo) directly to Excl.R. Especially if the application is buggy > Another case is when a program has it's own memory management routines that first initialize memory with zeros and then call VG_USERREQ__HG_CLEAN_MEMORY. This way the memory will be "New" but a read from it is quite legal. yea i have changed and i got better results. Tahnk you Ali |
|
From: Ali J. <a.j...@gm...> - 2008-01-31 09:11:18
|
Hi Julian
> [quick check: you are subscribed to valgrind-developers, yes?
> some messages about thread checking go only there]
Yes since few weeks i am.
> What I can do is to help to provide an evaluation. I can:
>
> * commit the 64-bit SVal patch, so you don't both have to
> include it in your own work
I have done some minor changes in your 64 bit schema as I needed in ShM2
lset, tset and TSegments.
> * fix the signed/unsigned Word problem that is now in hg_wordfm.c
Could be helpful
>
> * try out your patched versions on OOo / Firefox, and compare/
> summarise results.
>
> Is that useful?
This could be very useful to have an overview and compare the MSMs. I am
doing a review on my changes pls use the new patch that I will send you
after my revision.
I will run Konstatntin unittest with "MSMUnika" and will send you the
results.
> One comment about your MSM. It is often possible for memory
> to change from Virgin ("New" is a better name, imo) directly
> to Excl.R. Especially if the application is buggy (reading
> uninitialised memory) or due to compiler tricks, where the
> compiler loads a word from memory, part of which is uninitialised,
> and then does not use the uninitialised part. So you should add
> an edge for this transition to your Figure 1.
In the new version I changed and got a better results. thanks
Ali
|
|
From: Bart V. A. <bar...@gm...> - 2008-01-31 07:02:53
|
On Jan 29, 2008 10:36 PM, <sv...@va...> wrote: > --- trunk/docs/internals/3_3_BUGSTATUS.txt 2008-01-29 21:35:25 UTC (rev 7362) > +++ trunk/docs/internals/3_3_BUGSTATUS.txt 2008-01-29 21:36:47 UTC (rev 7363) > @@ -27,3 +27,5 @@ > > r7355 7356 33 155929 ms_print fails on massif outputs > containing long lines > + > +r7361 7362 33 n-i-bz ms_print broken for --time-unit=ms What are the criteria for adding a bug to this list ? I recently logged http://bugs.kde.org/show_bug.cgi?id=156404, but as far as I know this issue is not yet in the 3_3_BUGSTATUS.txt file. Bart. |
|
From: <sv...@va...> - 2008-01-31 05:01:24
|
Author: njn Date: 2008-01-31 05:01:18 +0000 (Thu, 31 Jan 2008) New Revision: 7365 Log: fix typo Modified: branches/VALGRIND_3_3_BRANCH/massif/docs/ms-manual.xml Modified: branches/VALGRIND_3_3_BRANCH/massif/docs/ms-manual.xml =================================================================== --- branches/VALGRIND_3_3_BRANCH/massif/docs/ms-manual.xml 2008-01-31 05:00:42 UTC (rev 7364) +++ branches/VALGRIND_3_3_BRANCH/massif/docs/ms-manual.xml 2008-01-31 05:01:18 UTC (rev 7365) @@ -735,7 +735,7 @@ <sect1 id="ms-manual.fileformat" xreflabel="fileformat"> <title>Massif's output file format</title> <para>Massif's file format is plain text (i.e. not binary) and deliberately -easy to read for both humands and machines. Nonetheless, the exact format +easy to read for both humans and machines. Nonetheless, the exact format is not described here. This is because the format is currently very Massif-specific. We plan to make the format more general, and thus suitable for possible use with other tools. Once this has been done, the format will |
|
From: <sv...@va...> - 2008-01-31 05:00:44
|
Author: njn Date: 2008-01-31 05:00:42 +0000 (Thu, 31 Jan 2008) New Revision: 7364 Log: fix typo Modified: trunk/massif/docs/ms-manual.xml Modified: trunk/massif/docs/ms-manual.xml =================================================================== --- trunk/massif/docs/ms-manual.xml 2008-01-29 21:36:47 UTC (rev 7363) +++ trunk/massif/docs/ms-manual.xml 2008-01-31 05:00:42 UTC (rev 7364) @@ -735,7 +735,7 @@ <sect1 id="ms-manual.fileformat" xreflabel="fileformat"> <title>Massif's output file format</title> <para>Massif's file format is plain text (i.e. not binary) and deliberately -easy to read for both humands and machines. Nonetheless, the exact format +easy to read for both humans and machines. Nonetheless, the exact format is not described here. This is because the format is currently very Massif-specific. We plan to make the format more general, and thus suitable for possible use with other tools. Once this has been done, the format will |
|
From: Tom H. <th...@cy...> - 2008-01-31 04:07:41
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2008-01-31 03:15:07 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 == 339 tests, 84 stderr failures, 1 stdout failure, 29 post failures == memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/long_namespace_xml (stderr) memcheck/tests/lsframe1 (stderr) memcheck/tests/lsframe2 (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/noisy_child (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/supp_unknown (stderr) memcheck/tests/x86/bug152022 (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/xor-undef-x86 (stderr) memcheck/tests/xml1 (stderr) massif/tests/alloc-fns-A (post) massif/tests/alloc-fns-B (post) massif/tests/basic (post) massif/tests/basic2 (post) massif/tests/big-alloc (post) massif/tests/culling1 (stderr) massif/tests/culling2 (stderr) massif/tests/custom_alloc (post) massif/tests/deep-A (post) massif/tests/deep-B (stderr) massif/tests/deep-B (post) massif/tests/deep-C (stderr) massif/tests/deep-C (post) massif/tests/deep-D (post) massif/tests/ignoring (post) massif/tests/insig (post) massif/tests/long-names (post) massif/tests/long-time (post) massif/tests/new-cpp (post) massif/tests/null (post) massif/tests/one (post) massif/tests/overloaded-new (post) massif/tests/peak (post) massif/tests/peak2 (stderr) massif/tests/peak2 (post) massif/tests/realloc (stderr) massif/tests/realloc (post) massif/tests/thresholds_0_0 (post) massif/tests/thresholds_0_10 (post) massif/tests/thresholds_10_0 (post) massif/tests/thresholds_10_10 (post) massif/tests/thresholds_5_0 (post) massif/tests/thresholds_5_10 (post) massif/tests/zero1 (post) massif/tests/zero2 (post) none/tests/blockfault (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/hg06_readshared (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc02_simple_tls (stderr) helgrind/tests/tc03_re_excl (stderr) helgrind/tests/tc04_free_lock (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc10_rec_lock (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc12_rwl_trivial (stderr) helgrind/tests/tc13_laog1 (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) helgrind/tests/tc24_nonzero_sem (stderr) exp-drd/tests/fp_race (stderr) exp-drd/tests/fp_race2 (stderr) exp-drd/tests/matinv (stderr) exp-drd/tests/pth_barrier (stderr) exp-drd/tests/pth_broadcast (stderr) exp-drd/tests/pth_cond_race (stderr) exp-drd/tests/pth_cond_race2 (stderr) exp-drd/tests/pth_create_chain (stderr) exp-drd/tests/pth_detached (stderr) exp-drd/tests/pth_detached2 (stderr) exp-drd/tests/sem_as_mutex (stderr) exp-drd/tests/sem_as_mutex2 (stderr) exp-drd/tests/sigalrm (stderr) exp-drd/tests/tc17_sembar (stderr) exp-drd/tests/tc18_semabuse (stderr) |
|
From: Tom H. <th...@cy...> - 2008-01-31 03:47:55
|
Nightly build on aston ( x86_64, Fedora Core 5 ) started at 2008-01-31 03:20: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 == 375 tests, 15 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/supp_unknown (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/blockfault (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) exp-drd/tests/pth_cond_race (stderr) exp-drd/tests/sem_as_mutex2 (stderr) |
|
From: Tom H. <th...@cy...> - 2008-01-31 03:39:49
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2008-01-31 03:05:11 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 == 373 tests, 8 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) exp-drd/tests/pth_cond_race (stderr) |
|
From: Tom H. <th...@cy...> - 2008-01-31 03:39:02
|
Nightly build on trojan ( x86_64, Fedora Core 6 ) started at 2008-01-31 03:25:05 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 == 373 tests, 7 stderr failures, 5 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/bug133694 (stdout) memcheck/tests/x86/bug133694 (stderr) memcheck/tests/x86/scalar (stderr) none/tests/cmdline1 (stdout) none/tests/cmdline2 (stdout) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) exp-drd/tests/sem_as_mutex2 (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 == 373 tests, 6 stderr failures, 5 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/bug133694 (stdout) memcheck/tests/x86/bug133694 (stderr) memcheck/tests/x86/scalar (stderr) none/tests/cmdline1 (stdout) none/tests/cmdline2 (stdout) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Thu Jan 31 03:32:19 2008 --- new.short Thu Jan 31 03:39:05 2008 *************** *** 8,10 **** ! == 373 tests, 6 stderr failures, 5 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) --- 8,10 ---- ! == 373 tests, 7 stderr failures, 5 stdout failures, 0 post failures == memcheck/tests/pointer-trace (stderr) *************** *** 20,21 **** --- 20,22 ---- helgrind/tests/tc22_exit_w_lock (stderr) + exp-drd/tests/sem_as_mutex2 (stderr) |
|
From: Tom H. <th...@cy...> - 2008-01-31 03:29:32
|
Nightly build on dellow ( x86_64, Fedora 8 ) started at 2008-01-31 03:10:05 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 == 373 tests, 9 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_detached (stdout) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) exp-drd/tests/pth_cond_race (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 == 373 tests, 9 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) exp-drd/tests/pth_cond_race (stderr) ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Thu Jan 31 03:19:53 2008 --- new.short Thu Jan 31 03:29:34 2008 *************** *** 8,10 **** ! == 373 tests, 9 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) --- 8,10 ---- ! == 373 tests, 9 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) *************** *** 16,17 **** --- 16,18 ---- none/tests/mremap2 (stdout) + none/tests/pth_detached (stdout) helgrind/tests/tc18_semabuse (stderr) |
|
From: Tom H. <th...@cy...> - 2008-01-31 03:15:26
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2008-01-31 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 == 375 tests, 30 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/stack_switch (stderr) memcheck/tests/supp_unknown (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/blockfault (stderr) none/tests/fdleak_fcntl (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) |