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
(9) |
2
(16) |
|
3
(9) |
4
(8) |
5
(9) |
6
(10) |
7
(14) |
8
(10) |
9
(7) |
|
10
(14) |
11
(19) |
12
(22) |
13
(18) |
14
(20) |
15
(10) |
16
(12) |
|
17
(13) |
18
(7) |
19
(12) |
20
(13) |
21
(9) |
22
(12) |
23
(6) |
|
24
(5) |
25
(5) |
26
(6) |
27
(7) |
28
(9) |
29
(13) |
30
(21) |
|
From: <sv...@va...> - 2006-09-13 22:57:43
|
Author: weidendo
Date: 2006-09-13 23:57:38 +0100 (Wed, 13 Sep 2006)
New Revision: 6064
Log:
callgrind_annotate: fix warnings with "--collect-jumps=3Dyes"
This callgrind option produces lines starting e.g. with
"jfi" in the profile data files, which specifies a
source file change between a jump source and jump target.
This itself is meaningless for callgrind_annotate, as
it can not show jump information in its annotation.
However, such "jfi" lines can contain important mapping
info for a (file ID, file name) tuple - which leads to
further warnings and problems if ignored.
Modified:
trunk/callgrind/callgrind_annotate.in
Modified: trunk/callgrind/callgrind_annotate.in
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/callgrind/callgrind_annotate.in 2006-09-12 23:08:49 UTC (rev 60=
63)
+++ trunk/callgrind/callgrind_annotate.in 2006-09-13 22:57:38 UTC (rev 60=
64)
@@ -634,6 +634,16 @@
} elsif (s/^(jump|jcnd)=3D//) {
#ignore jump information
=20
+ } elsif (s/^jfi=3D(.*)$//) {
+ # side effect needed: possibly add compression mapping=20
+ uncompressed_name("fl",$1);
+ # ignore jump information=09
+
+ } elsif (s/^jfn=3D(.*)$//) {
+ # side effect needed: possibly add compression mapping
+ uncompressed_name("fn",$1);
+ # ignore jump information
+
} elsif (s/^totals:\s+//) {
#ignore
=20
|
|
From: Bart V. A. <bar...@gm...> - 2006-09-13 20:13:35
|
The way I learned about vector clocks was via attending a presentation about the subject. If you're reading about vector clocks, then probably it's also interesting to know what a matrix clock is. I didn't read it yet, but maybe this paper or one of its citations is also interesting: http://www.cs.uic.edu/~ajayk/ext/DC2004.pdf . I hope you have some background in partial orders ? On 9/13/06, Julian Seward <js...@ac...> wrote: > > On Wednesday 13 September 2006 20:33, Bart Van Assche wrote: > > I think the algorithm outlined below will work. > > Oh .. and I've started to read Friedemann Mattern's paper "Virtual > Time and Global States of Distributed Systems" to get some theoretical > underpinning for the vector clock algorithm which is crucial to all > this. It looks really interesting. If you know of any better > references, let me know. > |
|
From: Bart V. A. <bar...@gm...> - 2006-09-13 19:53:27
|
A proposal for storing the (pthread_t, ThreadId) relationship in such a way that the scheduler's state machine doesn't have to be modified: - Add a client request such that a thread can query it's ThreadId from client space. - Implement a thread-safe data structure in the client that allows each thread to store its own ThreadId (thread-local storage can't be used for this purpose since each thread can only access it's own thread-local storage, and not that of another thread). - After each call to pthread_create(), store the (pthread_t, ThreadId) of the newly created thread in the just described data structure (e.g. at the beginning of vg_thread_wrapper()). Only allow pthread_create() to return after the (pthread_t, ThreadId) info has been stored, in order to avoid race conditions. - In the wrapper of pthread_join(), before the actual call of pthread_join(), obtain the ThreadId of the joined thread from that data structure. Next, call the actual pthread_join() function and do the post-thread-join client request. Next, remove the (pthread_t, ThreadId) info from the same data structure. - For detached threads, remove the (pthread_t, ThreadId) info at the time the thread is detached (this is either at thread creation time or at the time pthread_detach() is called). On 8/26/06, Bart Van Assche <bar...@gm...> wrote: > > Hello Julian, > > Regarding thread state: I commented out tst->status = VgTs_Empty in > the assembly code cited below because I moved it to another point > (m_scheduler.c, case VG_USERREQ__POST_PTHREAD_JOIN). The background of this > change is as follows: > - After the client finished calling pthread_join(), drd needs to know both > the thread IDs of the thread that called pthread_join() and the the ID of > the joined thread. Once pthread_join() finishes, the client knows the > identity of both threads, but both IDs are of type pthread_t. > - drd uses ThreadId's internally. Hence, I needed a way to map pthread_t > into ThreadId. I had two options for storing the translation data between > these two types of thread IDs: either in the Valgrind core or in the client. > > - When storing the translation information between pthread_t and ThreadId > in Valgrind, this translation information must still be accessible at the > time VG_USERREQ__POST_PTHREAD_JOIN is handled. This is why I postponed > cleanup of the per-thread data in Valgrind. > - Another option is to store the relationship between pthread_t and > ThreadId in the client. I can't solve this with thread-local storage since > this information is no longer accessible once pthread_join() completes > (pthread_key_create()/pthread_key_delete()/pthread_setspecific()/pthread_getspecific()). > > > Note: this change breaks clone() calls that do not originate from > pthread_create(). This can be solved by initializing the pthread_t value > kept for threads created by raw clone() calls to zero, and by executing the > statement "movl %1, %0\n" conditionally (only for threads created by raw > clone() calls). I did not yet implement this byself because I'm not that > fluent in assembly language. > |
|
From: Julian S. <js...@ac...> - 2006-09-13 19:51:14
|
On Wednesday 13 September 2006 20:33, Bart Van Assche wrote: > I think the algorithm outlined below will work. Oh .. and I've started to read Friedemann Mattern's paper "Virtual Time and Global States of Distributed Systems" to get some theoretical underpinning for the vector clock algorithm which is crucial to all this. It looks really interesting. If you know of any better references, let me know. J |
|
From: Julian S. <js...@ac...> - 2006-09-13 19:48:58
|
On Wednesday 13 September 2006 20:33, Bart Van Assche wrote: > I think the algorithm outlined below will work. Computing the danger set at > each context switch will take some CPU time, It might be possible to compute the danger set lazily. Rather than, at each context switch, constructing the union of relevant access sets, just remember which sets need to be unioned. Then, build parts of the union on demand and cache the result. This means that very short segments are not burdened with the potentially overwhelming cost of building the entire set at once. In effect it changes the cost per context switch from O(size of access sets of all segments unordered relative to this one) to O(the number of different memory locations this segment will visit) which sounds like a worthwhile improvement. > but has the big advantage that > precise call stacks can be reported without having to store a call stack > for each memory access. There is a difference however between reporting > races at the end of a segment versus reporting them immediately: when > reporting each race immediately, it becomes possible that the same data > race is reported more than once (e.g. when the same address is accessed > repeatedly in a loop). Probably care will have to be taken to ensure that > each race is only reported once. Yes. I agree. One cheap way to do this would be, once an error is reported for an address, remove that address from the danger set, so any further accesses to it in the remainder of this segment's run will not be reported. J |
|
From: Bart V. A. <bar...@gm...> - 2006-09-13 19:33:50
|
I think the algorithm outlined below will work. Computing the danger set at each context switch will take some CPU time, but has the big advantage that precise call stacks can be reported without having to store a call stack for each memory access. There is a difference however between reporting races at the end of a segment versus reporting them immediately: when reporting each race immediately, it becomes possible that the same data race is reported more than once (e.g. when the same address is accessed repeatedly in a loop). Probably care will have to be taken to ensure that each race is only reported once. On 9/4/06, Julian Seward <js...@ac...> wrote: > > > > data races. E.g. the ThreadChecker that is part of Intel VTune reports > the > > complete call stack for both first and second accesses involved in a > data > > race. The granularity of this information is one source line: an > overview > > Is the following a useful idea? It would give a complete call stack for > the second access in each data race and requires acceptable memory > overhead. > All assuming there are no flaws in the idea. > > ------- > > First, forget about the suggestion I made previously in this thread. > The following builds on the vanilla drd implementation that already > exists. > > We can take advantage of the fact that V only allows one thread to run > at any time. When a thread is scheduled for execution, compute a > "danger set". This is the set of memory locations accessed by the > union of segments which are unordered relative to the segment which is > about to be scheduled. (ie, the usual deal). > > As the segment runs, check each load and store against the danger set. > If the load/store addresses exist in the danger set, we know that the > standard drd algorithm will eventually flag them as race addresses. > So we might as well print a backtrace right now; then at least we will > know the backtrace of this second access. > > In short the idea is to do the segment comparison incrementally, rather > than wait until segment completion, as in the current implementation. > This is possible because V's one-thread-at-a-time means only one > segment is ever changing at any one time. > > The overheads are: > > (1) for each load and store, not only do we need to mark the current > segment's bitmaps; now we also need to check the danger set too. > Not great, but tolerable. > > (2) for each thread scheduling, need to construct the danger set. > Could possibly be optimised; eg if a thread repeatedly stops for > (eg) syscalls and then resumes, and no other thread runs in between, > can reuse existing danger set. > > (3) Extra space required to store the danger set. > > So the question is, will it work, or did I miss something? > > Consider two segments, A and B, both available to run, not ordered, and > containing a conflicting address. Does the scheme guarantee still to > detect the conflict? I believe so. > > - Suppose the scheduling is such that A visits the conflicting address > X for the first time before B does. Then, for all subsequent > scheduling(s) of B, X will be in the danger-set for B; hence if > B accesses X then the conflict will be found. > > - Same argument the other way round if B visits the conflicting address > first. > > Suppose A visits the conflicting address first, but there is a > synchronising > event between A and B before B visits that address for the first time. > Then A and B acquire an ordering (A < B), so A's accesses are no longer > included in B's danger set, and so no conflict is reported (which is > correct; > there is no race). Of course this is just a restatement of the normal > Diota > algorithm; it is not unique to the suggested modification. > |
|
From: Bart V. A. <bar...@gm...> - 2006-09-13 19:18:14
|
You're right: the sem_...() family of functions has to be supported as well. On 8/27/06, Julian Seward <js...@ac...> wrote: > > > > The following functions still have to be intercepted: > > pthread_mutex_trylock(), the rwlock family and the barrier-related > > functions. The last two families of functions are AFAIK not that > frequently > > used. > > What about the sem_init, sem_wait, sem_trywait, sem_post, sem_getvalue, > sem_destroy set of functions? > |
|
From: Bart V. A. <bar...@gm...> - 2006-09-13 19:13:59
|
Confirmed: I get the same issue with memcheck when the drd patch is there. It's not clear to me however why the client request is ignored. bart@pc-100:~/software/valgrind-svn> inst/bin/valgrind --tool=memcheck /bin/date ==5325== Memcheck, a memory error detector. ==5325== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==5325== Using LibVEX rev 1579, a library for dynamic binary translation. ==5325== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==5325== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation framework. ==5325== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==5325== For more details, rerun with: -v ==5325== Wed Sep 13 21:03:35 CEST 2006 ==5325== Invalid write of size 4 ==5325== at 0x401CBA9: _vgnU_freeres (vg_preloaded.c:66) ==5325== by 0x40D32A7: _Exit (in /lib/libc-2.4.so) ==5325== by 0x8049C3A: (within /bin/date) ==5325== by 0x405D87B: (below main) (in /lib/libc-2.4.so) ==5325== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==5325== ==5325== Process terminating with default action of signal 11 (SIGSEGV) ==5325== Access not within mapped region at address 0x0 ==5325== at 0x401CBA9: _vgnU_freeres (vg_preloaded.c:66) ==5325== by 0x40D32A7: _Exit (in /lib/libc-2.4.so) ==5325== by 0x8049C3A: (within /bin/date) ==5325== by 0x405D87B: (below main) (in /lib/libc-2.4.so) ==5325== ==5325== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 5 from 1) ==5325== malloc/free: in use at exit: 0 bytes in 0 blocks. ==5325== malloc/free: 424 allocs, 424 frees, 19,912 bytes allocated. ==5325== For counts of detected errors, rerun with: -v ==5325== All heap blocks were freed -- no leaks are possible. On 9/10/06, Dirk Mueller <dm...@gm...> wrote: > > On Sunday, 10. September 2006 10:23, Julian Seward wrote: > > > Ah, you mentioned this a couple of weeks ago. I installed openSuse 10.2 > > alpha 3 for x86 on vmware, but couldn't reproduce this problem with the > > svn trunk - all the regression tests looked ok. Are you sure you don't > > have some confusion with header files, such as accidentally picking up > > the header files (valgrind.h, memcheck.h) from a 3.1.X install? > > I found out that it was caused by the DRD patch. No client request besides > the > drd ones seemed to work anymore. > |
|
From: Julian S. <js...@ac...> - 2006-09-13 19:06:14
|
> > +Release 3.2.1 (XX Sept 2006) > > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > +3.2.1 adds SSE3 support for x86 and amd64 > > I think it's worth mentioning the SSE3 instructions it doesn't support; I > can't remember their names, but IIRC there are two. Good point. Will do. J |
|
From: Nicholas N. <nj...@cs...> - 2006-09-13 16:37:34
|
On Wed, 13 Sep 2006, Julian Seward wrote: > A release candidate for 3.2.1 is available at > > http://www.valgrind.org/downloads/valgrind-3.2.1.RC1.tar.bz2 > MD5 (valgrind-3.2.1.RC1.tar.bz2) = 971892e55a5d8abc65e6e07dd060b5c2 > > Please download it and give it a try, especially if you have a > less mainstream setup and/or you have been in communication with > the developers regarding bugs in 3.2.0. I would particularly > appreciate confirmation that it works on current Fedora Rawhide > since I was unable to test it on that. > > I have already verified that it builds and runs regression tests > OK on the following platforms: > > x86: SuSE 10.0, SuSE 10.1, SuSE 10.2alpha3, Red Hat 7.3 > amd64: SuSE 10.1 > ppc32: SuSE 10.0 > ppc64: SuSE 10.1, SLES9 > > Assuming there are no major problems with it, I plan a final release > on Friday. Looks good on the Ubuntu box I just tried (not sure what distro version, if someone reminds me how to find out I can check). Just 6 regtest failures, all harmless-looking: == 237 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_exit_group (stderr) memcheck/tests/x86/scalar_supp (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) Nick |
|
From: Nicholas N. <nj...@cs...> - 2006-09-13 16:02:47
|
On Wed, 13 Sep 2006 sv...@va... wrote: > +Release 3.2.1 (XX Sept 2006) > +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > +3.2.1 adds SSE3 support for x86 and amd64 I think it's worth mentioning the SSE3 instructions it doesn't support; I can't remember their names, but IIRC there are two. Nick |
|
From: Julian S. <js...@ac...> - 2006-09-13 14:44:58
|
A release candidate for 3.2.1 is available at http://www.valgrind.org/downloads/valgrind-3.2.1.RC1.tar.bz2 MD5 (valgrind-3.2.1.RC1.tar.bz2) = 971892e55a5d8abc65e6e07dd060b5c2 Please download it and give it a try, especially if you have a less mainstream setup and/or you have been in communication with the developers regarding bugs in 3.2.0. I would particularly appreciate confirmation that it works on current Fedora Rawhide since I was unable to test it on that. I have already verified that it builds and runs regression tests OK on the following platforms: x86: SuSE 10.0, SuSE 10.1, SuSE 10.2alpha3, Red Hat 7.3 amd64: SuSE 10.1 ppc32: SuSE 10.0 ppc64: SuSE 10.1, SLES9 Assuming there are no major problems with it, I plan a final release on Friday. J On Tuesday 12 September 2006 21:39, Julian Seward wrote: > I intend to roll a test tarball for 3.2.1 in the next 24 hours, and > will make it available for testing. 3.2.1 incorporates a lot of > fixes over 3.2.0, and it's become obvious that attempting to fix all > reported 3.2.0 bugs before releasing 3.2.1 would result in infinite > further delay, since bugs are being reported faster than they get fixed. > It seems better to draw a line and release, with the plan to follow up > with 3.2.2 some time in December. > > 3.2.0 isn't particularly buggy (as far as I can tell - I thought it a > good, stable release). My impression why so many bugs have been reported > is that the user base is growing and so more people are pushing the > boundaries of the system. > > J > > ------------------------------------------------------------------------- > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job > easier Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: <js...@ac...> - 2006-09-13 11:54:57
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-09-13 09:00:01 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 == 207 tests, 10 stderr failures, 6 stdout failures, 0 posttest failures == memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/leakotron (stdout) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigaltstack (stderr) memcheck/tests/xml1 (stderr) none/tests/faultstatus (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: Tom H. <to...@co...> - 2006-09-13 02:46:29
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-09-13 03:30: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 == 240 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/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-09-13 02:25:58
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-09-13 03:10:08 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 == 268 tests, 4 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/mempool (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) |
|
From: Tom H. <th...@cy...> - 2006-09-13 02:24:43
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-09-13 03:15:02 BST Results differ from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccToYyth.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccToYyth.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccToYyth.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccToYyth.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccToYyth.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccToYyth.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccToYyth.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccToYyth.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.17476/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.17476/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.17476/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.17476/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.17476/valgrind' make: *** [check] Error 2 ================================================= == Results from 24 hours ago == ================================================= Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Last 20 lines of verbose log follow echo /tmp/ccbHJpFl.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbHJpFl.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbHJpFl.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbHJpFl.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbHJpFl.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbHJpFl.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbHJpFl.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccbHJpFl.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 rm insn_mmx.c insn_sse2.c insn_fpu.c insn_mmxext.c insn_sse.c insn_sse3.c insn_cmov.c insn_basic.c make[5]: Leaving directory `/tmp/valgrind.17476/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.17476/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.17476/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.17476/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.17476/valgrind' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Sep 13 03:19:49 2006 --- new.short Wed Sep 13 03:24:33 2006 *************** *** 7,16 **** Last 20 lines of verbose log follow echo ! /tmp/ccbHJpFl.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbHJpFl.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbHJpFl.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbHJpFl.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbHJpFl.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbHJpFl.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbHJpFl.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccbHJpFl.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 --- 7,16 ---- Last 20 lines of verbose log follow echo ! /tmp/ccToYyth.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccToYyth.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccToYyth.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccToYyth.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccToYyth.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccToYyth.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccToYyth.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccToYyth.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 |
|
From: Tom H. <th...@cy...> - 2006-09-13 02:20:02
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2006-09-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 == 268 tests, 6 stderr failures, 2 stdout failures, 0 posttest failures == memcheck/tests/leakotron (stdout) memcheck/tests/mempool (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. <th...@cy...> - 2006-09-13 02:16:37
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-09-13 03:00:03 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 == 270 tests, 6 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/mempool (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) |