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
(11) |
4
(12) |
5
(11) |
|
6
(9) |
7
(13) |
8
(6) |
9
(7) |
10
(7) |
11
(11) |
12
(13) |
|
13
(7) |
14
(6) |
15
(7) |
16
(19) |
17
(20) |
18
(9) |
19
(9) |
|
20
(6) |
21
(7) |
22
(11) |
23
(16) |
24
(14) |
25
(24) |
26
(16) |
|
27
(20) |
28
(58) |
29
(7) |
30
(10) |
31
(15) |
|
|
|
From: Dirk M. <mu...@kd...> - 2006-08-26 19:46:06
|
On Saturday, 26. August 2006 18:22, Bart Van Assche wrote:
> - Various small changes.
I assume you noticed anyway, but the new snapshot doesn't compile. Here's the
diff.
--- drd/drd_main.c.orig 2006-08-26 21:43:36.000000000 +0200
+++ drd/drd_main.c 2006-08-26 21:43:56.000000000 +0200
@@ -110,7 +110,7 @@
addr, size, VG_(get_running_tid)());
}
#endif
- sg = thread_get_segment(VG_(running_tid));
+ sg = thread_get_segment(VG_(get_running_tid));
bm_access_range(sg->bm, addr, size, eLoad);
}
@@ -124,7 +124,7 @@
addr, size, VG_(get_running_tid)());
}
#endif
- sg = thread_get_segment(VG_(running_tid));
+ sg = thread_get_segment(VG_(get_running_tid));
bm_access_range(sg->bm, addr, size, eStore);
}
Dirk
|
|
From: Bart V. A. <bar...@gm...> - 2006-08-26 18:07:42
|
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.
Do you have any suggestions for alternative implementations ?
On 8/26/06, Julian Seward <js...@ac...> wrote:
>
>
>
> asm volatile (
> - "movl %1, %0\n" /* set tst->status = VgTs_Empty */
> + // "movl %1, %0\n" /* set tst->status = VgTs_Empty */
> "movl %2, %%eax\n" /* set %eax = __NR_exit */
> "movl %3, %%ebx\n" /* set %ebx = tst->os_state.exitcode */
> "int $0x80\n" /* exit(tst->os_state.exitcode) */
>
> etc. So, I'm really not enthusiastic about messing with the
> scheduler's state machine. You made some comment about why this
> is necessary, but now I can't find that email. Something to do
> with clone?
>
|
|
From: Bart V. A. <bar...@gm...> - 2006-08-26 16:22:20
|
Hello,
I have applied the following changes to the drd prototype:
- Fixed huge memory leak (thanks Julian !).
- Support for Ist_Dirty with side effects (Julian's patch).
- Cleanup of error reporting.
- Disabled malloc()/free() and friends wrappers.
- Removed #include "drd/drd_clientreq.h" from coregrind/vg_preloaded.c.
- Various small changes.
Source code:
http://home.scarlet.be/~bvassche/drd/valgrind-6012.patch
http://home.scarlet.be/~bvassche/drd/valgrind-6012-drd-2006-08-26.tar.bz2
What I consider now as a priority is to get drd working on pth_cvsimple.
Anyone any idea what the behavior of Valgrind is when a wrapper is defined
in vg_preloaded.c for a function that is defined in multiple shared
libraries (e.g. pthread_mutex_lock()) ?
|
|
From: Bart V. A. <bar...@gm...> - 2006-08-26 12:53:39
|
Julian, you made the following comment regarding the Valgrind patch I
proposed:
> Mostly it looks ok; however I'd prefer to first stabilise drd itself
> and to get some more experience and understanding of what it can/can't
> do. Anyway, some questions:
>
> ------
>
> +/* pthread_t as handled internally in valgrind. */
> +typedef UInt PosixThreadId;
>
> Uh, is that a portable assumption, that a Posix thread id is a
> 32-bit int? Maybe better would be UWord.
The new comment I added in pub_tool_basics.h should clarify this:
Index: pub_tool_basics.h
===================================================================
--- pub_tool_basics.h (revision 6012)
+++ pub_tool_basics.h (working copy)
@@ -97,6 +97,15 @@
/* ThreadIds are simply indices into the VG_(threads)[] array. */
typedef UInt ThreadId;
+/* A PosixThreadId identifies uniquely a POSIX thread in the client. This
datatype must
+ be able to represent any client pthread_t value. The only operations
performed on
+ this datatype are copying and comparison (==). Note: the POSIX standard
specifies
+ that POSIX thread IDs may be implemented as a struct, and that these
must be
+ compared by calling pthread_equal(). Representing POSIX thread IDs by an
integer is
+ a shortcut that works (at least) on Linux.
+ */
+typedef UWord PosixThreadId;
+
/* An abstraction of syscall return values.
When .isError == False, val holds the return value.
When .isError == True, val holds the error code.
|
|
From: Bart V. A. <bar...@gm...> - 2006-08-26 12:21:25
|
Hello Julian, I don't have an answer yet why drd fails on pth_cvsimple. But when I enable mutex tracing in drd, it looks like threads 2 and 3 were able to both lock count_lock. How can I verify that the pthread_mutex_lock() implementation of libpthread.so.0 is called and not the implementation of libc.so.6 ? For most pthread functions there are dummy implementation present in glibc. > inst/bin/valgrind --tool=drd --trace-mutex=yes none/tests/pth_cvsimple ==13717== drd, a data race detector. ==13717== Copyright (C) 2006, and GNU GPL'd, by Bart Van Assche. THIS SOFTWARE IS A PROTOTYPE, AND IS NOT YET RELEASED ==13717== Using LibVEX rev 1579, a library for dynamic binary translation. ==13717== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==13717== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation framework. ==13717== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==13717== For more details, rerun with: -v ==13717== --13717-- drd_post_mutex_lock tid = 1, mutex 0x401B2E0 rc 0 owner 0 --13717-- drd_pre_mutex_unlock tid = 1, mutex 0x401B2E0 rc 1 owner 1 --13717-- drd_post_mutex_lock tid = 2, mutex 0x8049A48 rc 0 owner 0 --13717-- drd_post_mutex_lock tid = 3, mutex 0x8049A48 rc 1 owner 2 --13717-- The impossible happened: mutex 0x8049A48 is locked simultaneously by two threads (recursion count 1, owners 2 and 3) ! drd: drd_mutex.c:96 (mutex_lock): the 'impossible' happened. ==13717== at 0x38007585: report_and_quit (m_libcassert.c:136) ==13717== by 0x380078AF: vgPlain_assert_fail (m_libcassert.c:200) ==13717== by 0x380021B8: mutex_lock (drd_mutex.c:96) ==13717== by 0x380016F3: drd_post_mutex_lock (drd_main.c:202) ==13717== by 0x380265EE: do_client_request (scheduler.c:1256) ==13717== by 0x38027C5B: vgPlain_scheduler (scheduler.c:872) ==13717== by 0x38046B63: run_a_thread_NORETURN (syswrap-linux.c:87) ==13717== by 0x38046DC3: vgModuleLocal_start_thread_NORETURN ( syswrap-linux.c:207) ==13717== by 0x38049088: (within /home/bart/software/valgrind-svn/inst/lib/valgrind/x86-linux/drd) ==13717== by 0x382450AF: temporary (in /home/bart/software/valgrind-svn/inst/lib/valgrind/x86-linux/drd) ==13717== by 0x8: ??? sched status: running_tid=3 Thread 1: status = VgTs_Yielding ==13717== at 0x410A648: clone (in /lib/libc-2.4.so) ==13717== by 0x403E9BC: pthread_create@@GLIBC_2.1 (in /lib/libpthread- 2.4.so) ==13717== by 0x401CAAF: pthread_create@* (vg_preloaded.c:135) ==13717== by 0x80486FF: main (pth_cvsimple.c:68) Thread 2: status = VgTs_WaitSys ==13717== at 0x40417E6: pthread_cond_wait@@GLIBC_2.3.2 (in /lib/libpthread-2.4.so) ==13717== by 0x401CB3A: vg_thread_wrapper (vg_preloaded.c:109) ==13717== by 0x403E34A: start_thread (in /lib/libpthread-2.4.so) ==13717== by 0x410A65D: clone (in /lib/libc-2.4.so) Thread 3: status = VgTs_Runnable ==13717== at 0x401C71D: pthread_mutex_lock (vg_preloaded.c:211) ==13717== by 0x80485F5: inc_count (pth_cvsimple.c:34) ==13717== by 0x401CB3A: vg_thread_wrapper (vg_preloaded.c:109) ==13717== by 0x403E34A: start_thread (in /lib/libpthread-2.4.so) ==13717== by 0x410A65D: clone (in /lib/libc-2.4.so) |
|
From: Bart V. A. <bar...@gm...> - 2006-08-26 11:40:07
|
Julian, you made the following comment about drd: > - Only print a stack trace if the data address is identified as being > in a heap block. I tried to find where in your code this is done, > but failed. This is the code that does the error reporting (drd_bitmap3.c): VG_(maybe_record_error)(tid1, DataRaceErr, VG_(get_IP)(tid1), "data race", &dri); It was also my desire not to print a stack trace in this case, and have each data race counted as an error. Is this possible with Valgrind ? By this time I have replaced the above statement by a call to VG_(message)(...). |
|
From: <js...@ac...> - 2006-08-26 10:35:39
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-08-26 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: Julian S. <js...@ac...> - 2006-08-26 08:59:36
|
> The actual text in the output is "Detected data races.", which is short f=
or
> "The drd tool detected some data races". Each time the drd tool detects
> data races, it prints the following chunks of information:
> - call stack of segment begin and end in the first involved thread.
> - call stack of segment begin and end in the second involved thread.
> - 32-bit addresses in the client address space of the data involved in the
> race. Above this last section the text "Actual race" is printed. Maybe I
> should change this in "Addresses of detected data races" ?
Ok, I finally understood this.
=46rom time to time drd wants to report a race. To do so it shows
five pieces of information:
=2D stack snapshot at start of first segment
=2D stack snapshot at end of first segment
=2D stack snapshot at start of second segment
=2D stack snapshot at end of second segment
=2D address(es) of data involved in the race
=46or the data address(es), drd tries to describe the address as well
as possible, eg:
0x06723B10 sz 1 W R (heap, offset 112 in block at 0x6723AA0 of size 124)
Allocation context:
at 0x401B1E8: operator new(unsigned) (vg_replace_malloc.c:163)
by 0x4112B2A: KNNetAccess::KNNetAccess(QObject*, char const*)
(knnetaccess.cpp:60)
by 0x4112BAE: KNGlobals::netAccess() (knglobals.cpp:53)
but sometimes it fails to come up with any description:
0x05B70E59 sz 1 W R (unknown)
I think there are two reasons for my confusion.
(1) In the case where it cannot describe the address, or where is is
just described as BSS, TEXT, etc, there is still
a stack trace printed. This trace is irrelevant (correct?)
(2) The terminology could be improved, and you could make it clearer
where each report starts/ends.
Here's a possible tidy-up:
=2D Remove "Detected data races. Context:" and just print instead a line
of dashes:
----------------------------------------------------------
so as to make it obvious that this is the start of a new error
=2D Change "Actual data races:" to "Data addresses accessed by both segment=
s"
=2D Only print a stack trace if the data address is identified as being
in a heap block. I tried to find where in your code this is done,
but failed.
J
|
|
From: Julian S. <js...@ac...> - 2006-08-26 08:46:39
|
> > good and if Julian is also happy I don't see why it can't be added now --
> > it's almost all code that shouldn't affect existing tools.
Mostly it looks ok; however I'd prefer to first stabilise drd itself
and to get some more experience and understanding of what it can/can't
do. Anyway, some questions:
------
+/* pthread_t as handled internally in valgrind. */
+typedef UInt PosixThreadId;
Uh, is that a portable assumption, that a Posix thread id is a
32-bit int? Maybe better would be UWord.
------
asm volatile (
- "movl %1, %0\n" /* set tst->status = VgTs_Empty */
+ // "movl %1, %0\n" /* set tst->status = VgTs_Empty */
"movl %2, %%eax\n" /* set %eax = __NR_exit */
"movl %3, %%ebx\n" /* set %ebx = tst->os_state.exitcode */
"int $0x80\n" /* exit(tst->os_state.exitcode) */
etc. So, I'm really not enthusiastic about messing with the
scheduler's state machine. You made some comment about why this
is necessary, but now I can't find that email. Something to do
with clone?
J
|
|
From: Julian S. <js...@ac...> - 2006-08-26 07:59:19
|
> So the next question is, why doe the malloc/free intercepting > cost ~940MB for konq? It appears drd_malloc_wrappers.c was freeing shadow chunks but not the payload data itself. The attached drd_diffs2.txt, which is again relative to valgrind-5999-drd-2006-08-14.tar.bz2, fixes this problem. I also did a bit of inlining and loop unrolling in drd_bitmap3.c so as to make bm_access_4 faster. I think that fixes the resource problems. konq now starts and exits, even with malloc/free intercepting, in 160M, which is much more reasonable. So I guess we can move on to the questions: - is it robust? - does it find real bugs? I tested it on the following: none/tests/pth_mutexspeed.c none/tests/pth_rwlock.c none/tests/pth_once.c none/tests/pth_cvsimple.c with results: pth_mutexspeed.c - runs ok, no races reported pth_rwlock.c - runs ok, no races reported pth_once.c - runs ok, but many races reported pth_cvsimple.c - drd_mutex.c:95 (mutex_lock): the 'impossible' happened. Bart, can you look at pth_once and pth_cvsimple? It may be that glibc contains some races - I believe we found with Helgrind that there is a statistics counter to do with dynamic linking, which is not protected by a mutex, and the glibc maintainers had no interest in fixing it. However, I still don't understand what it is telling me for pth_once. J |
|
From: Tom H. <th...@cy...> - 2006-08-26 04:08:37
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-08-26 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 == 266 tests, 6 stderr failures, 2 stdout failures, 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) none/tests/tls (stdout) |
|
From: <js...@ac...> - 2006-08-26 02:59:32
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-08-26 03:30:01 BST 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 == 236 tests, 5 stderr failures, 1 stdout failure, 0 posttest failures == memcheck/tests/leak-tree (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...> - 2006-08-26 02:46:10
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-08-26 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 == 238 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-08-26 02:25:02
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-08-26 03:10:02 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 == 264 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-08-26 02:24:22
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-08-26 03:15:01 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/ccMfNnY6.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccMfNnY6.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccMfNnY6.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccMfNnY6.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccMfNnY6.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccMfNnY6.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccMfNnY6.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccMfNnY6.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.25721/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.25721/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.25721/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.25721/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.25721/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/cc8oMclZ.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc8oMclZ.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc8oMclZ.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc8oMclZ.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc8oMclZ.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc8oMclZ.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc8oMclZ.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc8oMclZ.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.25721/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.25721/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.25721/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.25721/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.25721/valgrind' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Sat Aug 26 03:19:41 2006 --- new.short Sat Aug 26 03:24:16 2006 *************** *** 7,16 **** Last 20 lines of verbose log follow echo ! /tmp/cc8oMclZ.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc8oMclZ.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc8oMclZ.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc8oMclZ.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc8oMclZ.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc8oMclZ.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc8oMclZ.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc8oMclZ.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/ccMfNnY6.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccMfNnY6.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccMfNnY6.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccMfNnY6.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccMfNnY6.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccMfNnY6.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccMfNnY6.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccMfNnY6.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 |
|
From: Tom H. <th...@cy...> - 2006-08-26 02:20:38
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2006-08-26 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 == 264 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) |