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: Bart V. A. <bar...@gm...> - 2006-08-23 20:04:59
|
On 8/23/06, Julian Seward <js...@ac...> wrote: > > > > I have done some tests, and the huge memory consumption is probably due > to > > a memory leak when doing segment deallocation. > > It would probably help if you allocated the bitmaps using > VG_(am_shadow_alloc) rather than VG_(malloc). (grep for > examples of usage). This reduces the extent to which client and > shadow address spaces are interleaved. > One problem with VG_(am_shadow_alloc) is you can't then free the > result (ever); but you could put "freed" bitmaps on a freelist > and first allocate from there. Does that make sense? It's > worth a try. Can you try it? As soon as I have time, but I don't have that much spare time currently :-( > > 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: [...] > > It helps, but (1) it still does not define the terms "detected race" > and "actual race", and (2) you also need to say what a vector clock is. > The actual text in the output is "Detected data races.", which is short for "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" ? Regarding vector clocks: is the following Wiki clear enough ? http://en.wikipedia.org/wiki/Vector_clocks In the diagram A, B and C correspond to threads. |
|
From: Julian S. <js...@ac...> - 2006-08-23 19:39:10
|
> I have done some tests, and the huge memory consumption is probably due to > a memory leak when doing segment deallocation. It would probably help if you allocated the bitmaps using VG_(am_shadow_alloc) rather than VG_(malloc). (grep for examples of usage). This reduces the extent to which client and shadow address spaces are interleaved. One problem with VG_(am_shadow_alloc) is you can't then free the result (ever); but you could put "freed" bitmaps on a freelist and first allocate from there. Does that make sense? It's worth a try. Can you try it? I mentioned this because a similar problem bit me during early development of memcheck. If the shadow data (bitmaps) and client data end up being finely interleaved in the address space, then much of the shadow data is covering areas of address space which is occupied by shadow data (if you see what I mean) and so the space usage can become very inefficient. This is the first thing I would try. > Was my explanation comprehensible, or should I illustrate it with a picture > ? You mean this message? > 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: [...] It helps, but (1) it still does not define the terms "detected race" and "actual race", and (2) you also need to say what a vector clock is. > BTW: thanks for the patch ! No probs. Nice to see drd progressing. J |
|
From: Julian S. <js...@ac...> - 2006-08-23 19:30:31
|
On Wednesday 23 August 2006 20:24, Bart Van Assche wrote: > On 8/22/06, Josef Weidendorfer <Jos...@gm...> wrote: > > On Tuesday 22 August 2006 18:18, Bart Van Assche wrote: > > > > 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. > > Josef, you're right about this. Not recording read and write accesses until > a second thread is created would be a nice optimization of the drd tool. That is indeed try (and the DIOTA paper mentions exactly this optimisation); however I would prefer first to simplify the memory management scenario as much as possible until we can figure out what's going on, and fix it. > I have tried to disable malloc()/free() wrapping, but I didn't see an > obvious difference in memory consumption of the drd tool. No, maybe not, but let's leave it disabled for now since that gives a simpler situation to debug. J |
|
From: Bart V. A. <bar...@gm...> - 2006-08-23 19:24:53
|
On 8/22/06, Josef Weidendorfer <Jos...@gm...> wrote: > > On Tuesday 22 August 2006 18:18, Bart Van Assche wrote: > > 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. Josef, you're right about this. Not recording read and write accesses until a second thread is created would be a nice optimization of the drd tool. 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. > I have tried to disable malloc()/free() wrapping, but I didn't see an obvious difference in memory consumption of the drd tool. |
|
From: Bart V. A. <bar...@gm...> - 2006-08-23 19:21:48
|
On 8/23/06, Nicholas Nethercote <nj...@cs...> wrote: > > On Tue, 22 Aug 2006, Bart Van Assche wrote: > > > - 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? At the time free() is called from the client. BTW: pub_tool_execontext.h defines VG_(record_ExeContext)() but no corresponding cleanup function ? > 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? The current bitmap implementation splits each 32-bit address in 10+10+12 bits -- that means that the lowest level corresponds to 4096 client bytes. > 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? >From the DIOTA sources (DIOTA-0.91-20060222/backend_dr/bitmap10c.c): each 32-bit address is split as follows: 32 = 1+3+3+3+3+3+3+3+3+2+5 (that's 10 levels in total -- the 9 levels was OTOH). BTW, do you know/are you involved with the DIOTA people? Judging from your > name it seems plausible :) During several years I shared an office with Michiel Ronsse at the University of Ghent -- that's where I learned about DIOTA. I already told him about drd. In the past Michiel has tried to attract a student for writing a tool like drd, but without success. |
|
From: Bart V. A. <bar...@gm...> - 2006-08-23 19:12:14
|
On 8/22/06, Julian Seward <js...@ac...> wrote: > > > 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? I have done some tests, and the huge memory consumption is probably due to a memory leak when doing segment deallocation. The memory used by drd keeps increasing for programs like konqueror or kate even although the number of segments kept in memory is limited to 16 for single-threaded programs. Even when I decreased this limit to max. 1 segment in memory at a time, memory consumption kept increasing ... (2) Nick asked: > > > What's the difference between detected and actual races? > > 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. > Was my explanation comprehensible, or should I illustrate it with a picture ? BTW: thanks for the patch ! |
|
From: Bart V. A. <bar...@gm...> - 2006-08-23 16:53:04
|
Hello Nicholas,
Thanks for the feedback. I'll split up my Valgrind patch, small
modifications will be easier to discuss.
On 8/19/06, Nicholas Nethercote <nj...@cs...> wrote:
>
> On Fri, 18 Aug 2006, Bart Van Assche wrote:
>
> > A question for the Valgrind developers: I have made changes to
> Valgrind's
> > core in order to get the drd tool working. How should I proceed to get
> these
> > changes applied to the official Valgrind distribution ? Should I split
> up
> > the patch ? Should I wait until after release 3.x.y ?
>
> I just looked again through your patch at
> http://home.scarlet.be/~bvassche/drd/valgrind-5999.patch. Much of it
> looks
> 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.
>
|
|
From: Dirk M. <dmu...@su...> - 2006-08-23 14:42:40
|
On Tuesday 22 August 2006 21:54, Josef Weidendorfer wrote: > 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. I've commented out that part, but it still OOMs quickly. My guess is that there is some simple error in the bitmap'ing. How reusable is the compressed bitmap stuff done for memcheck? can we reuse it here? Dirk |
|
From: <js...@ac...> - 2006-08-23 10:22:21
|
Nightly build on minnie ( SuSE 10.0, ppc32 ) started at 2006-08-23 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: <sv...@va...> - 2006-08-23 08:27:10
|
Author: tom
Date: 2006-08-23 09:27:03 +0100 (Wed, 23 Aug 2006)
New Revision: 6009
Log:
Hand assemble cmpxchg16b as old assemblers don't understand it.
Modified:
trunk/none/tests/amd64/bug127521-64.c
Modified: trunk/none/tests/amd64/bug127521-64.c
=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/none/tests/amd64/bug127521-64.c 2006-08-17 01:54:15 UTC (rev 60=
08)
+++ trunk/none/tests/amd64/bug127521-64.c 2006-08-23 08:27:03 UTC (rev 60=
09)
@@ -83,7 +83,7 @@
"\tmovq 16(%%r11),%%rcx\n"
"\tmovq 24(%%r11),%%rbx\n"
"\tmovq 32(%%r11),%%r10\n"
- "\tlock cmpxchg16b (%%r10)\n"
+ "\t.byte 0xf0, 0x49, 0x0f, 0xc7, 0x0a\n" /* lock cmpxchg16b (%%r=
10) */
"\tmovabsq $0,%%r10\n"
"\tsetz %%r10b\n"
"\tmovq %%r10,40(%%r11)\n"
|
|
From: Tom H. <th...@cy...> - 2006-08-23 07:39:26
|
Nightly build on lloyd ( x86_64, Fedora Core 3 ) started at 2006-08-23 08:31:17 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.10188/valgrind/none/tests/x86' Making check in amd64 make[4]: Entering directory `/tmp/valgrind.10188/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.10188/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/ccSiUXIp.s: Assembler messages: /tmp/ccSiUXIp.s:220: Error: no such instruction: `cmpxchg16b (%r10)' make[5]: *** [bug127521-64.o] Error 1 make[5]: Leaving directory `/tmp/valgrind.10188/valgrind/none/tests/amd64' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.10188/valgrind/none/tests/amd64' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.10188/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.10188/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.10188/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.10188/valgrind/none/tests/x86' Making check in amd64 make[4]: Entering directory `/tmp/valgrind.10188/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.10188/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/ccbg6QZD.s: Assembler messages: /tmp/ccbg6QZD.s:220: Error: no such instruction: `cmpxchg16b (%r10)' make[5]: *** [bug127521-64.o] Error 1 make[5]: Leaving directory `/tmp/valgrind.10188/valgrind/none/tests/amd64' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.10188/valgrind/none/tests/amd64' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.10188/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.10188/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.10188/valgrind' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Aug 23 08:35:16 2006 --- new.short Wed Aug 23 08:39:20 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/ccbg6QZD.s: Assembler messages: ! /tmp/ccbg6QZD.s:220: 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/ccSiUXIp.s: Assembler messages: ! /tmp/ccSiUXIp.s:220: Error: no such instruction: `cmpxchg16b (%r10)' make[5]: *** [bug127521-64.o] Error 1 |
|
From: <js...@ac...> - 2006-08-23 03:04:07
|
Nightly build on phoenix ( SuSE 10.0 ) started at 2006-08-23 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-23 02:45:57
|
Nightly build on dunsmere ( athlon, Fedora Core 5 ) started at 2006-08-23 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-23 02:25:35
|
Nightly build on dellow ( x86_64, Fedora Core 5 ) started at 2006-08-23 03:10:05 BST Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 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-23 02:24:40
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2006-08-23 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/ccZfSu6c.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccZfSu6c.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccZfSu6c.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccZfSu6c.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccZfSu6c.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccZfSu6c.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccZfSu6c.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccZfSu6c.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.16244/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.16244/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.16244/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.16244/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.16244/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/ccTaUIIU.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccTaUIIU.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccTaUIIU.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccTaUIIU.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccTaUIIU.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccTaUIIU.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccTaUIIU.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' /tmp/ccTaUIIU.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.16244/valgrind/none/tests/x86' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.16244/valgrind/none/tests/x86' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.16244/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.16244/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.16244/valgrind' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Aug 23 03:19:46 2006 --- new.short Wed Aug 23 03:24:33 2006 *************** *** 7,16 **** Last 20 lines of verbose log follow echo ! /tmp/ccTaUIIU.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccTaUIIU.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccTaUIIU.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccTaUIIU.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccTaUIIU.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccTaUIIU.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccTaUIIU.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccTaUIIU.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/ccZfSu6c.s:4393: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccZfSu6c.s:4513: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccZfSu6c.s:4633: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccZfSu6c.s:4753: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccZfSu6c.s:4873: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccZfSu6c.s:4993: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccZfSu6c.s:5113: Error: no such instruction: `fisttpq -56(%ebp)' ! /tmp/ccZfSu6c.s:5233: Error: no such instruction: `fisttpq -56(%ebp)' make[5]: *** [insn_sse3.o] Error 1 |
|
From: Tom H. <th...@cy...> - 2006-08-23 02:17:05
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2006-08-23 03:00: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 make[4]: Leaving directory `/tmp/valgrind.26747/valgrind/none/tests/x86' Making check in amd64 make[4]: Entering directory `/tmp/valgrind.26747/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.26747/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/ccCn0ePe.s: Assembler messages: /tmp/ccCn0ePe.s:241: Error: no such instruction: `cmpxchg16b (%r10)' make[5]: *** [bug127521-64.o] Error 1 make[5]: Leaving directory `/tmp/valgrind.26747/valgrind/none/tests/amd64' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.26747/valgrind/none/tests/amd64' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.26747/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.26747/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.26747/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.26747/valgrind/none/tests/x86' Making check in amd64 make[4]: Entering directory `/tmp/valgrind.26747/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.26747/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/ccFIP4tV.s: Assembler messages: /tmp/ccFIP4tV.s:241: Error: no such instruction: `cmpxchg16b (%r10)' make[5]: *** [bug127521-64.o] Error 1 make[5]: Leaving directory `/tmp/valgrind.26747/valgrind/none/tests/amd64' make[4]: *** [check-am] Error 2 make[4]: Leaving directory `/tmp/valgrind.26747/valgrind/none/tests/amd64' make[3]: *** [check-recursive] Error 1 make[3]: Leaving directory `/tmp/valgrind.26747/valgrind/none/tests' make[2]: *** [check-recursive] Error 1 make[2]: Leaving directory `/tmp/valgrind.26747/valgrind/none' make[1]: *** [check-recursive] Error 1 make[1]: Leaving directory `/tmp/valgrind.26747/valgrind' make: *** [check] Error 2 ================================================= == Difference between 24 hours ago and now == ================================================= *** old.short Wed Aug 23 03:08:19 2006 --- new.short Wed Aug 23 03:16:55 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/ccFIP4tV.s: Assembler messages: ! /tmp/ccFIP4tV.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/ccCn0ePe.s: Assembler messages: ! /tmp/ccCn0ePe.s:241: Error: no such instruction: `cmpxchg16b (%r10)' make[5]: *** [bug127521-64.o] Error 1 |