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: Nicholas N. <nj...@cs...> - 2006-08-22 23:10:30
|
On Tue, 22 Aug 2006, Bart Van Assche wrote: > - The drd tool records the order in which segments are executed. Within a > thread, this order is represented by a single integer number. The order over > threads is represented by something called a "vector clock". This is a > standard way of representing the partial order relationship between actions > performed by different threads. > - For each segment it is recorded via a three-level bitmap which memory > locations have been read from or written to (at the lowest level, two bits > are needed per byte: one bit representing read access, one representing > write access). I'd guess that this is where the memory consumption is coming from. > - A data race is defined as two threads that access the same memory > location, where at least one of the two threads performs a write action, and > the order between the two accesses is not enforced by a synchronization > action. > - Segments that can no longer be involved in a data race are freed > (VG_(free)()). That sounds important. When can they be freed? > This means that the memory consumption of the drd tool is proportional to: > - the number of threads running simultaneously. > - the number of segments allocated within a thread. > - the amount of unused memory allocated within the bitmap allocated for a > segment. When e.g. iterating over a byte-array, and only reading every > 1024th byte, only 0.1% of the memory allocated for the bitmap will be used > -- very inefficient. So 1024 bytes is the smallest memory chunk you can individually represent? > It must be possible however to run software like konqueror under drd, since > it is possible with DIOTA. DIOTA uses the same approach as drd. One of the > differences between DIOTA and drd that I know of, is that DIOTA uses a > 9-level bitmap while drd only uses a 3-level bitmap. Wow, 9 levels sounds like total overkill. How small are the memory chunks then? BTW, do you know/are you involved with the DIOTA people? Judging from your name it seems plausible :) > I hope the above explanation is comprehensible ? It helps a lot! Thanks. Nick |
|
From: Josef W. <Jos...@gm...> - 2006-08-22 19:54:50
|
On Tuesday 22 August 2006 18:18, Bart Van Assche wrote: > ... > This means that the memory consumption of the drd tool is proportional to: > - the number of threads running simultaneously. > - the number of segments allocated within a thread. > - the amount of unused memory allocated within the bitmap allocated for a > segment. When e.g. iterating over a byte-array, and only reading every > 1024th byte, only 0.1% of the memory allocated for the bitmap will be used > -- very inefficient. > > Or: it's not yet clear to me which of the above three reasons applies to > konqueror. Hmmm... AFAIK, konqueror does not do multithreading. Why does drd for the 1-threaded "segment" at process start already need to store read/write accesses? I would say that there can never be any race until a second thread is created. Or I am wrong and the drd tool is not storing read/write accesses for konqueror, but only the 500627 (*) mallocs with stack traces for potential later error messages. Josef (*) This is only konqueror startup, until the blank window appears (KDE 3.5.3). Just checked with callgrind... |
|
From: Bart V. A. <bar...@gm...> - 2006-08-22 16:18:47
|
Hello Julian,
Regarding interception of malloc() and free(): the only reason drd
intercepts those is for recording the call stack at the time malloc() is
called, such that this call stack can be included when reporting a data
race. I don't think this causes a lot of overhead ?
Before I can say something about the memory use of drd, I have to
explain its algorithm. In short, the data race detection algorithm works as
follows:
- A process being analyzed by drd consists of a number of threads.
- Each thread consists of a sequence of actions. The actions relevant to drd
are: memory load, memory store, and synchronization actions (lock mutex,
unlock mutex, create thread, join thread, ...).
- The sequence of load and stores performed by a single thread between two
successive synchronization actions is called a segment.
- The drd tool records the order in which segments are executed. Within a
thread, this order is represented by a single integer number. The order over
threads is represented by something called a "vector clock". This is a
standard way of representing the partial order relationship between actions
performed by different threads.
- For each segment it is recorded via a three-level bitmap which memory
locations have been read from or written to (at the lowest level, two bits
are needed per byte: one bit representing read access, one representing
write access).
- Actions within a thread are always ordered, actions performed by different
threads are only considered as ordered when an order has been enforced by
synchronization actions.
- A data race is defined as two threads that access the same memory
location, where at least one of the two threads performs a write action, and
the order between the two accesses is not enforced by a synchronization
action.
- Segments that can no longer be involved in a data race are freed
(VG_(free)()).
This means that the memory consumption of the drd tool is proportional to:
- the number of threads running simultaneously.
- the number of segments allocated within a thread.
- the amount of unused memory allocated within the bitmap allocated for a
segment. When e.g. iterating over a byte-array, and only reading every
1024th byte, only 0.1% of the memory allocated for the bitmap will be used
-- very inefficient.
Or: it's not yet clear to me which of the above three reasons applies to
konqueror.
It must be possible however to run software like konqueror under drd, since
it is possible with DIOTA. DIOTA uses the same approach as drd. One of the
differences between DIOTA and drd that I know of, is that DIOTA uses a
9-level bitmap while drd only uses a 3-level bitmap.
I hope the above explanation is comprehensible ?
On 8/22/06, Julian Seward <js...@ac...> wrote:
>
>
> > So now, I can start konqueror and it runs for ~ 60 seconds
> > (doing fontconfig crap) but I had to control-C it before the konq
> > window appeared, due to memory use exceeding 450MB.
>
> Update: I can get the konq main window, but it exhausts my 2G swap
> partition before it can render the first page. At the point the process
> died its total size was using about 2600M. Watching it with top,
> there were many places where it seemed to increase in size at a
> rate of almost 20MB/sec, and I believe it averaged 10MB/sec overall.
>
> One thing I observe is that you're intercepting malloc/free. Is that
> necessary? Does that make the algorithm work better somehow?
>
> J
>
--
Met vriendelijke groeten,
Bart Van Assche.
|
|
From: Julian S. <js...@ac...> - 2006-08-22 10:48:02
|
> So now, I can start konqueror and it runs for ~ 60 seconds > (doing fontconfig crap) but I had to control-C it before the konq > window appeared, due to memory use exceeding 450MB. Update: I can get the konq main window, but it exhausts my 2G swap partition before it can render the first page. At the point the process died its total size was using about 2600M. Watching it with top, there were many places where it seemed to increase in size at a rate of almost 20MB/sec, and I believe it averaged 10MB/sec overall. One thing I observe is that you're intercepting malloc/free. Is that necessary? Does that make the algorithm work better somehow? J |
|
From: <js...@ac...> - 2006-08-22 10:18:00
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-08-22 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: <js...@ac...> - 2006-08-22 03:01:51
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-08-22 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-22 02:46:15
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-08-22 03:30:04 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: Julian S. <js...@ac...> - 2006-08-22 02:35:22
|
> A proof-of-concept version of drd is available at the following location:
Just trying it now.
> This version is not yet ready for a release -- e.g. it does not yet support
> floating-point instructions,
Huh? I guess you mean it does not handle the dirty helper calls used
for doing x87 80-bit loads/stores. I rewrote the Ist_Dirty case in
drd_instrument() in drd_main.c as shown below and that appears to fix
it (at least it does not die on fldt/fstpt). For the Ifx_Modify case
I called drd_trace_load and then drd_trace_store with the same args
since there is no drd_trace_modify function. Is that OK ?
So now, I can start konqueror and it runs for ~ 60 seconds
(doing fontconfig crap) but I had to control-C it before the konq
window appeared, due to memory use exceeding 450MB.
So it looks promising. At this point I have two questions:
(1) The memory use .. seems huge.
Can you say what it is that the memory use depends on?
Is there a worst-case bound?
Can the current behaviour be improved?
(2) Nick asked:
> What's the difference between detected and actual races?
>
The output of the drd tool is structured as follows:
- First the text "Detected data races. Context:".
[ ...]
So .. I read all this but still didn't understand what the
meaning of these phrases is. Can you clarify?
If the tool is to become popular we need to have a way to
explain to programmers in a simple way what it does and how
to interpret the results. I for one would like to know .. at
the moment all I know is that it finds data races by some
entirely mysterious means, and gives fewer false positives
than the Eraser style algorithms.
J
-----
Patch for drd_instrument() in drd_main.c to make x86 FP work:
(replaces entire previous Ist_Dirty case)
case Ist_Dirty:
{
IRDirty* d = st->Ist.Dirty.details;
IREffect const mFx = d->mFx;
switch (mFx) {
case Ifx_None:
break;
case Ifx_Read:
case Ifx_Write:
case Ifx_Modify:
tl_assert(d->mAddr);
tl_assert(d->mSize > 0);
argv = mkIRExprVec_2(d->mAddr, mkIRExpr_HWord(d->mSize));
if (mFx == Ifx_Read || mFx == Ifx_Modify) {
di = unsafeIRDirty_0_N(
/*regparms*/2,
"drd_trace_load",
VG_(fnptr_to_fnentry)(drd_trace_load),
argv);
addStmtToIRBB(bb, IRStmt_Dirty(di));
}
if (mFx == Ifx_Write || mFx == Ifx_Modify) {
di = unsafeIRDirty_0_N(
/*regparms*/2,
"drd_trace_store",
VG_(fnptr_to_fnentry)(drd_trace_store),
argv);
addStmtToIRBB(bb, IRStmt_Dirty(di));
}
break;
default:
tl_assert(0);
}
}
addStmtToIRBB(bb, st);
break;
|
|
From: Tom H. <th...@cy...> - 2006-08-22 02:26:13
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-08-22 03:10: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, 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-22 02:24:49
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-08-22 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/ccmynWwa.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccmynWwa.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccmynWwa.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccmynWwa.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccmynWwa.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccmynWwa.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccmynWwa.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccmynWwa.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.17046/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.17046/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.17046/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.17046/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.17046/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/cc0IdMLQ.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc0IdMLQ.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc0IdMLQ.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc0IdMLQ.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc0IdMLQ.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc0IdMLQ.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc0IdMLQ.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/cc0IdMLQ.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.17046/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.17046/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.17046/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.17046/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.17046/valgrind' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Tue Aug 22 03:19:50 2006 --- new.short Tue Aug 22 03:24:43 2006 *************** *** 7,16 **** Last 20 lines of verbose log follow echo ! /tmp/cc0IdMLQ.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc0IdMLQ.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc0IdMLQ.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc0IdMLQ.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc0IdMLQ.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc0IdMLQ.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc0IdMLQ.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/cc0IdMLQ.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/ccmynWwa.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccmynWwa.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccmynWwa.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccmynWwa.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccmynWwa.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccmynWwa.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccmynWwa.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccmynWwa.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 |
|
From: Tom H. <th...@cy...> - 2006-08-22 02:21:52
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-08-22 03:00:12 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 make[4]: Leaving directory `/tmp/valgrind.26602/valgrind/none/tests/x86' Making check in amd64 make[4]: Entering directory `/tmp/valgrind.26602/valgrind/none/tests/amd64' make bug127521-64 clc faultstatus fcmovnu fxtract insn_basic insn_mmx insn_sse insn_sse2 insn_sse3 insn_fpu looper jrcxz smc1 shrld nibz_bennee_mmap make[5]: Entering directory `/tmp/valgrind.26602/valgrind/none/tests/amd64' if gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -Winline -Wall -Wshadow -g -I../../../include -Wno-long-long -Wdeclaration-after-statement -MT bug127521-64.o -MD -MP -MF ".deps/bug127521-64.Tpo" -c -o bug127521-64.o bug127521-64.c; \ then mv -f ".deps/bug127521-64.Tpo" ".deps/bug127521-64.Po"; else rm -f ".deps/bug127521-64.Tpo"; exit 1; fi /tmp/cc6bNyl6.s: Assembler messages: /tmp/cc6bNyl6.s:241: Error: no such instruction: `cmpxchg16b (%r10)' make[5]: *** [bug127521-64.o] Error 1 make[5]: Leaving directory `/tmp/valgrind.26602/valgrind/none/tests/amd64' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.26602/valgrind/none/tests/amd64' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.26602/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.26602/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.26602/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 make[4]: Leaving directory `/tmp/valgrind.26602/valgrind/none/tests/x86' Making check in amd64 make[4]: Entering directory `/tmp/valgrind.26602/valgrind/none/tests/amd64' make bug127521-64 clc faultstatus fcmovnu fxtract insn_basic insn_mmx insn_sse insn_sse2 insn_sse3 insn_fpu looper jrcxz smc1 shrld nibz_bennee_mmap make[5]: Entering directory `/tmp/valgrind.26602/valgrind/none/tests/amd64' if gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -Winline -Wall -Wshadow -g -I../../../include -Wno-long-long -Wdeclaration-after-statement -MT bug127521-64.o -MD -MP -MF ".deps/bug127521-64.Tpo" -c -o bug127521-64.o bug127521-64.c; \ then mv -f ".deps/bug127521-64.Tpo" ".deps/bug127521-64.Po"; else rm -f ".deps/bug127521-64.Tpo"; exit 1; fi /tmp/ccLTwg2Z.s: Assembler messages: /tmp/ccLTwg2Z.s:241: Error: no such instruction: `cmpxchg16b (%r10)' make[5]: *** [bug127521-64.o] Error 1 make[5]: Leaving directory `/tmp/valgrind.26602/valgrind/none/tests/amd64' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.26602/valgrind/none/tests/amd64' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.26602/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.26602/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.26602/valgrind' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Tue Aug 22 03:12:39 2006 --- new.short Tue Aug 22 03:21:38 2006 *************** *** 14,17 **** then mv -f ".deps/bug127521-64.Tpo" ".deps/bug127521-64.Po"; else rm -f ".deps/bug127521-64.Tpo"; exit 1; fi ! /tmp/ccLTwg2Z.s: Assembler messages: ! /tmp/ccLTwg2Z.s:241: Error: no such instruction: `cmpxchg16b (%r10)' make[5]: *** [bug127521-64.o] Error 1 --- 14,17 ---- then mv -f ".deps/bug127521-64.Tpo" ".deps/bug127521-64.Po"; else rm -f ".deps/bug127521-64.Tpo"; exit 1; fi ! /tmp/cc6bNyl6.s: Assembler messages: ! /tmp/cc6bNyl6.s:241: Error: no such instruction: `cmpxchg16b (%r10)' make[5]: *** [bug127521-64.o] Error 1 |