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
(12) |
3
(19) |
4
(18) |
5
(22) |
6
(25) |
7
(18) |
8
(24) |
|
9
(16) |
10
(15) |
11
(22) |
12
(7) |
13
(19) |
14
(5) |
15
(8) |
|
16
(7) |
17
(8) |
18
(9) |
19
(7) |
20
(13) |
21
(16) |
22
(7) |
|
23
(10) |
24
(8) |
25
(4) |
26
(4) |
27
(9) |
28
(4) |
29
(5) |
|
30
(8) |
31
(4) |
|
|
|
|
|
|
From: John R.
|
I have an oracle who tells me that the child side of a particular clone() should not be monitored: valgrind should "let go" of the child (whether thread or fork) as soon as possible. Waiting for execve(), to let go as in "--trace-children=no", is not an option. What is a good way for valgrind let go relatively immediately? It looks like one option is to have a of ThreadState.exitReason of VgSrc_LetGo that behaves almost the same as VgSrc_ExitSyscall. But rather than calling sys_exit(), instead VgSrc_LetGo re-establishes the usercode signal handlers, then the usercode registers, and finally the usercode instruction pointer. Comments? -- John Reiser, jreiser@BitWagon.com |
|
From: Ashley P. <api...@co...> - 2007-12-08 23:28:56
|
On Sat, 2007-12-08 at 19:30 +0100, Julian Seward wrote: > We can fix Memcheck by falling back to the reference version, but I'd > like to see if there is a way to get the correct behaviour without > the extra conditionals. Perhaps you could right shift the value before putting it into the tree? Ashley, |
|
From: Nicholas N. <nj...@cs...> - 2007-12-08 23:12:14
|
On Sat, 8 Dec 2007, Christoph Bartoschek wrote: >> We can fix Memcheck by falling back to the reference version, but I'd >> like to see if there is a way to get the correct behaviour without >> the extra conditionals. > > I would propose that you use a hashtable for the entries with one of the > already used hashfunctions. You would get the following two benefits: > > - An amortized O(1) access time instead of O(log(n)) for all operations. > > - For some big programs (the ones I run) more than 70% of the memory > consumption of memcheck is for the entries of secVBitTable2. Using a > hashtable (preferably with a memory pool for the entries or a space efficient > memory manager) would save about 16-24 bytes per entry. I just spoke with Julian. For this release, we're just going to use the slower version that is correct. Any other change is too big at this late stage. After the release, we can look at using a hashtable instead. Christoph, if you are able to try using the hashtable instead and give us some performance numbers and a patch, that would be very helpful. Nick |
|
From: Christoph B. <bar...@or...> - 2007-12-08 19:29:11
|
Am Samstag, 8. Dezember 2007 schrieb Julian Seward: > > Yes. The relation established by the comparison function has to be > > transitive. This is not the case here. Therefore the function should not > > be used. > > > > I've shown how this affects the AVL tree in theory and implementation. > > This also fits one fact that Tom gives: There have to be additional > > additions and deletions to the tree till the values are not found. > > Below is a test program which compares comparison functions through > exhaustive testing. It shows immediately that the slow (reference) > and fast versions produce different results. > > We can fix Memcheck by falling back to the reference version, but I'd > like to see if there is a way to get the correct behaviour without > the extra conditionals. I would propose that you use a hashtable for the entries with one of the already used hashfunctions. You would get the following two benefits: - An amortized O(1) access time instead of O(log(n)) for all operations. - For some big programs (the ones I run) more than 70% of the memory consumption of memcheck is for the entries of secVBitTable2. Using a hashtable (preferably with a memory pool for the entries or a space efficient memory manager) would save about 16-24 bytes per entry. Christoph |
|
From: Julian S. <js...@ac...> - 2007-12-08 18:30:57
|
> Yes. The relation established by the comparison function has to be
> transitive. This is not the case here. Therefore the function should not be
> used.
>
> I've shown how this affects the AVL tree in theory and implementation. This
> also fits one fact that Tom gives: There have to be additional additions
> and deletions to the tree till the values are not found.
Below is a test program which compares comparison functions through
exhaustive testing. It shows immediately that the slow (reference)
and fast versions produce different results.
We can fix Memcheck by falling back to the reference version, but I'd
like to see if there is a way to get the correct behaviour without
the extra conditionals.
J
#include <stdio.h>
typedef signed char Char;
typedef unsigned char UChar;
Char cmp_slow_signed ( Char x, Char y ) {
if (x < y) return -1;
if (x > y) return 1;
return 0;
}
Char cmp_fast_signed ( Char x, Char y ) {
Char diff = x - y;
return diff;
}
void run_test_signed ( char* testname,
Char(*cmp1)(Char,Char),
Char(*cmp2)(Char,Char) )
{
unsigned int x, y;
printf("\n%s: start\n", testname);
for (x = 0; x < 256; x++) {
for (y = 0; y < 256; y++) {
Char r1 = cmp1( (Char)x, (Char)y );
Char r2 = cmp2( (Char)x, (Char)y );
if (r1 < 0 && r2 < 0) continue;
if (r1 > 0 && r2 > 0) continue;
if (r1 == 0 && r2 == 0) continue;
printf("%s: difference at %x %x\n\n", testname, x, y);
return;
}
}
printf("%s: success\n\n", testname);
}
int main ( void )
{
run_test_signed( "cmp_fast_signed",
cmp_slow_signed, cmp_fast_signed );
return 0;
}
|
|
From: Tom H. <to...@co...> - 2007-12-08 15:02:24
|
On Dec 8, 2007 12:02 PM, Julian Seward <js...@ac...> wrote: > > On Saturday 08 December 2007 12:10, Christoph Bartoschek wrote: > > > > In my opinion the problem is, that you have lost transitivity. Assume Word > > If transitivity is lost, then it means fast_cmp is broken. > > My current hypothesis is: the ordering of two N-bit signed words X, Y > cannot be correctly established by examining the sign of the N-bit > subtraction X - Y (which is what fast_cmp does). It is necessary to examine > N+1 bits of subtraction result to establish the correct ordering. I think > this is what John Reiser's comment about the carry flag means. I've established now (after writing more sanity check code for the AVL tree) that the problem is that the tree invariants are locally correct (so each node's children correctly compare as less than or greater than it ) but may be globally incorrect - so comparing a node to it's ancestors all the way up to the root may yield a result which is not correct. The attached patch adds just such a sanity check - it is expensive (order n squared in the size of the tree) as it recursively checks that, for each node, all the nodes in it's left subtree are less than it and all those in the right subtree greater than it. With my test case this sanity check fails unless I use Nick's modified fast_cmp routine. > This seems to fit the facts best of all: > > - Problem is not to do with gcc -fstrict-overflow. > > * That is a recent phenomenon (gcc-4.3 ?) and #147545 was > reported in early July. See my other mail - I am on gcc 4.1.2 here. > - Problem happened w/ Wine because perhaps Wine is doing some > wierd address space games, and/or Tom is running a 4G+4G kernel, so > there is stuff above 0xC000'0000 when there isn't usually. Well I'm using a 64 bit kernel, but am valgrinding a 32 bit process. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Tom H. <to...@co...> - 2007-12-08 14:55:28
|
On Dec 8, 2007 10:43 AM, Julian Seward <js...@ac...> wrote: > It's because ISO C says that overflow of signed arithmetic produces > undefined results, and recent gccs exploit that fact for optimisation > purposes. Note that overflow of unsigned arithmetic is still well > defined. If this is the problem then presumably another fix is to > use unsigned subtraction in fast_cmp. > > An interesting first experiment would be to build the unmodified sources > with and without -fno-strict-overflow and see if that changes the outcome. I'm using gcc 4.1.2 which doesn't have that option, and presumably not the overflow semantics issues that it is related to. Tom -- Tom Hughes (to...@co...) http://www.compton.nu/ |
|
From: Christoph B. <bar...@or...> - 2007-12-08 12:33:38
|
Am Samstag, 8. Dezember 2007 schrieb Julian Seward: > > On Saturday 08 December 2007 12:10, Christoph Bartoschek wrote: > > > > In my opinion the problem is, that you have lost transitivity. Assume > > Word > > If transitivity is lost, then it means fast_cmp is broken. Yes. The relation established by the comparison function has to be transitive. This is not the case here. Therefore the function should not be used. I've shown how this affects the AVL tree in theory and implementation. This also fits one fact that Tom gives: There have to be additional additions and deletions to the tree till the values are not found. Christoph |
|
From: Julian S. <js...@ac...> - 2007-12-08 12:03:06
|
> On Saturday 08 December 2007 12:10, Christoph Bartoschek wrote:
>
> In my opinion the problem is, that you have lost transitivity. Assume Word
If transitivity is lost, then it means fast_cmp is broken.
My current hypothesis is: the ordering of two N-bit signed words X, Y
cannot be correctly established by examining the sign of the N-bit
subtraction X - Y (which is what fast_cmp does). It is necessary to examine
N+1 bits of subtraction result to establish the correct ordering. I think
this is what John Reiser's comment about the carry flag means.
This seems to fit the facts best of all:
- Problem is not to do with gcc -fstrict-overflow.
* That is a recent phenomenon (gcc-4.3 ?) and #147545 was
reported in early July.
* I rebuilt V with gcc-4.3 -Wstrict-overflow=5 (max paranoia)
and got various warnings, but none about m_oset.c
- Problem is rarely seen because it requires entries in secVBitsTable
to have some specific relationship above and below the 0x8000'0000
midpoint line. Most programs don't use much of the address space
and so would be either entirely below or entirely above the line.
In any case PDBs are very rare.
- Problem happened w/ Wine because perhaps Wine is doing some
wierd address space games, and/or Tom is running a 4G+4G kernel, so
there is stuff above 0xC000'0000 when there isn't usually.
J
|
|
From: Julian S. <js...@ac...> - 2007-12-08 11:40:03
|
> > Hmm, yes. Wasn't there a giant storm in a teacup on the gcc list a while > > back about whether gcc should optimise on the basis that overflow of > > signed arithmetic is undefined? > > I don't understand why the carry bit is important... It's because ISO C says that overflow of signed arithmetic produces undefined results, and recent gccs exploit that fact for optimisation purposes. Note that overflow of unsigned arithmetic is still well defined. If this is the problem then presumably another fix is to use unsigned subtraction in fast_cmp. An interesting first experiment would be to build the unmodified sources with and without -fno-strict-overflow and see if that changes the outcome. J |
|
From: Christoph B. <bar...@or...> - 2007-12-08 11:10:32
|
Am Samstag, 8. Dezember 2007 schrieb Julian Seward:
> > I don't get the assertion until some more stuff has been added to
> > the tree - the reason is that although the tree is out of order that
> > node is at the root and is therefore found without having to decide
> > which way to go.
>
> But the tree isn't out of order, is it? I thought what you established
> on the way to the station is that the ordering is signed word ordering,
> not unsigned, yes?
In my opinion the problem is, that you have lost transitivity. Assume Word is
only 8 bits wide.
The range is -128 ... 127
Now there are three numbers:
a = -100
b = 0
c = 100
a - b = -100 < 0 ==> b > a
b - c = -100 < 0 ==> c > b
c - a = 200 == -56 < 0 ==> a > c
If you put a, b, c in this order in an AVL-Tree you get:
a
/ \
c b
Because b > a and c < a. Now we add e = -1 and f = 1 into the tree and
get:
a
/ \
c b
/ \
e f
One additional node: g = -2 results in this tree:
a
/ \
c b
/ \
e f
/
g
Now we violate the AVL conditions at node a and we have to rotate. The result
will be:
e
/ \
a b
/ \ \
c g f
Now searching for c will not succeed because c > e.
I have changed the createSecVBitTable function to show this error:
static OSet* createSecVBitTable(void)
{
SecVBitNode * n;
Addr aAligned;
OSet * set = VG_(OSetGen_Create)( offsetof(SecVBitNode, a),
NULL, // use fast comparisons
VG_(malloc), VG_(free) );
n = VG_(OSetGen_AllocNode)(set, sizeof(SecVBitNode));
n->a = 0x81000000;
VG_(OSetGen_Insert)(set, n);
n = VG_(OSetGen_AllocNode)(set, sizeof(SecVBitNode));
n->a = 0x0;
VG_(OSetGen_Insert)(set, n);
n = VG_(OSetGen_AllocNode)(set, sizeof(SecVBitNode));
n->a = 0x7F000000;
VG_(OSetGen_Insert)(set, n);
n = VG_(OSetGen_AllocNode)(set, sizeof(SecVBitNode));
n->a = 1;
VG_(OSetGen_Insert)(set, n);
n = VG_(OSetGen_AllocNode)(set, sizeof(SecVBitNode));
n->a = -1;
VG_(OSetGen_Insert)(set, n);
n = VG_(OSetGen_AllocNode)(set, sizeof(SecVBitNode));
n->a = -2;
VG_(OSetGen_Insert)(set, n);
aAligned = 0x0;
tl_assert2(VG_(OSetGen_Lookup)(set, &aAligned),
"Not found: %lu\n", aAligned);
aAligned = 0x7F000000;
tl_assert2(VG_(OSetGen_Lookup)(set, &aAligned),
"Not found: %lu\n", aAligned);
aAligned = 0x81000000;
tl_assert2(VG_(OSetGen_Lookup)(set, &aAligned),
"Not found: %lu\n", aAligned);
return set;
}
Greetings
Christoph
|
|
From: Nicholas N. <nj...@cs...> - 2007-12-08 05:41:50
|
On Sat, 8 Dec 2007, Julian Seward wrote: >>> they treat >>> the words as signed, do a subtraction, the result is treated as signed, >>> and the result is checked for < 0 or > 0. >> >> If the subtraction overflows then it is incorrect to compare the "result" >> (while forgetting about the Carry) to 0. > > Hmm, yes. Wasn't there a giant storm in a teacup on the gcc list a while > back about whether gcc should optimise on the basis that overflow of signed > arithmetic is undefined? I don't understand why the carry bit is important... But here's a patch that should fix the problem. It uses a slower but safer and easier-to-understand method to compute the result. Tom, can you apply and see if it fixes the problem? If so, I guess it should be committed for 3.3.0. Nick |
|
From: Tom H. <th...@cy...> - 2007-12-08 03:59:51
|
Nightly build on alvis ( i686, Red Hat 7.3 ) started at 2007-12-08 03:15:04 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 321 tests, 62 stderr failures, 1 stdout failure, 28 post failures == memcheck/tests/addressable (stderr) memcheck/tests/badjump (stderr) memcheck/tests/describe-block (stderr) memcheck/tests/erringfds (stderr) memcheck/tests/leak-0 (stderr) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-pool-0 (stderr) memcheck/tests/leak-pool-1 (stderr) memcheck/tests/leak-pool-2 (stderr) memcheck/tests/leak-pool-3 (stderr) memcheck/tests/leak-pool-4 (stderr) memcheck/tests/leak-pool-5 (stderr) memcheck/tests/leak-regroot (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/long_namespace_xml (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/match-overrun (stderr) memcheck/tests/noisy_child (stderr) memcheck/tests/partial_load_dflt (stderr) memcheck/tests/partial_load_ok (stderr) memcheck/tests/partiallydefinedeq (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/sigkill (stderr) memcheck/tests/stack_changes (stderr) memcheck/tests/x86/bug152022 (stderr) memcheck/tests/x86/scalar (stderr) memcheck/tests/x86/scalar_supp (stderr) memcheck/tests/x86/xor-undef-x86 (stderr) memcheck/tests/xml1 (stderr) massif/tests/alloc-fns-A (post) massif/tests/alloc-fns-B (post) massif/tests/basic (post) massif/tests/basic2 (post) massif/tests/big-alloc (post) massif/tests/culling1 (stderr) massif/tests/culling2 (stderr) massif/tests/custom_alloc (post) massif/tests/deep-A (post) massif/tests/deep-B (stderr) massif/tests/deep-B (post) massif/tests/deep-C (stderr) massif/tests/deep-C (post) massif/tests/deep-D (post) massif/tests/ignoring (post) massif/tests/insig (post) massif/tests/long-time (post) massif/tests/new-cpp (post) massif/tests/null (post) massif/tests/one (post) massif/tests/overloaded-new (post) massif/tests/peak (post) massif/tests/peak2 (stderr) massif/tests/peak2 (post) massif/tests/realloc (stderr) massif/tests/realloc (post) massif/tests/thresholds_0_0 (post) massif/tests/thresholds_0_10 (post) massif/tests/thresholds_10_0 (post) massif/tests/thresholds_10_10 (post) massif/tests/thresholds_5_0 (post) massif/tests/thresholds_5_10 (post) massif/tests/zero1 (post) massif/tests/zero2 (post) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/hg06_readshared (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc02_simple_tls (stderr) helgrind/tests/tc03_re_excl (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc12_rwl_trivial (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) helgrind/tests/tc24_nonzero_sem (stderr) |
|
From: Tom H. <th...@cy...> - 2007-12-08 03:37:40
|
Nightly build on lloyd ( x86_64, Fedora 7 ) started at 2007-12-08 03:05:15 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 355 tests, 7 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) |
|
From: Tom H. <th...@cy...> - 2007-12-08 03:28:06
|
Nightly build on dellow ( x86_64, Fedora 8 ) started at 2007-12-08 03:10:06 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 355 tests, 10 stderr failures, 3 stdout failures, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) memcheck/tests/vcpu_fnfns (stdout) memcheck/tests/x86/scalar (stderr) memcheck/tests/xml1 (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) none/tests/pth_detached (stdout) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc18_semabuse (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) |
|
From: Tom H. <th...@cy...> - 2007-12-08 03:14:00
|
Nightly build on gill ( x86_64, Fedora Core 2 ) started at 2007-12-08 03:00:02 GMT Results unchanged from 24 hours ago Checking out valgrind source tree ... done Configuring valgrind ... done Building valgrind ... done Running regression tests ... failed Regression test results follow == 357 tests, 24 stderr failures, 1 stdout failure, 0 post failures == memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (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) helgrind/tests/hg01_all_ok (stderr) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) |
|
From: Julian S. <js...@ac...> - 2007-12-08 01:34:51
|
On Saturday 08 December 2007 02:23, John Reiser wrote: > > they treat > > the words as signed, do a subtraction, the result is treated as signed, > > and the result is checked for < 0 or > 0. > > If the subtraction overflows then it is incorrect to compare the "result" > (while forgetting about the Carry) to 0. Hmm, yes. Wasn't there a giant storm in a teacup on the gcc list a while back about whether gcc should optimise on the basis that overflow of signed arithmetic is undefined? J |
|
From: <js...@ac...> - 2007-12-08 01:31:22
|
Nightly build on g5 ( SuSE 10.1, ppc970 ) started at 2007-12-08 02:00:01 CET 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 == 288 tests, 27 stderr failures, 2 stdout failures, 0 post failures == memcheck/tests/deep_templates (stdout) memcheck/tests/leak-cycle (stderr) memcheck/tests/leak-tree (stderr) memcheck/tests/malloc_free_fill (stderr) memcheck/tests/pointer-trace (stderr) none/tests/faultstatus (stderr) none/tests/fdleak_cmsg (stderr) none/tests/mremap (stderr) none/tests/mremap2 (stdout) helgrind/tests/hg02_deadlock (stderr) helgrind/tests/hg03_inherit (stderr) helgrind/tests/hg04_race (stderr) helgrind/tests/hg05_race2 (stderr) helgrind/tests/tc01_simple_race (stderr) helgrind/tests/tc05_simple_race (stderr) helgrind/tests/tc06_two_races (stderr) helgrind/tests/tc07_hbl1 (stderr) helgrind/tests/tc08_hbl2 (stderr) helgrind/tests/tc09_bad_unlock (stderr) helgrind/tests/tc11_XCHG (stderr) helgrind/tests/tc14_laog_dinphils (stderr) helgrind/tests/tc16_byterace (stderr) helgrind/tests/tc17_sembar (stderr) helgrind/tests/tc19_shadowmem (stderr) helgrind/tests/tc20_verifywrap (stderr) helgrind/tests/tc21_pthonce (stderr) helgrind/tests/tc22_exit_w_lock (stderr) helgrind/tests/tc23_bogus_condwait (stderr) helgrind/tests/tc24_nonzero_sem (stderr) |
|
From: John R.
|
> they treat > the words as signed, do a subtraction, the result is treated as signed, and > the result is checked for < 0 or > 0. If the subtraction overflows then it is incorrect to compare the "result" (while forgetting about the Carry) to 0. -- |
|
From: Julian S. <js...@ac...> - 2007-12-08 01:21:07
|
> I don't get the assertion until some more stuff has been added to > the tree - the reason is that although the tree is out of order that > node is at the root and is therefore found without having to decide > which way to go. But the tree isn't out of order, is it? I thought what you established on the way to the station is that the ordering is signed word ordering, not unsigned, yes? J |
|
From: Tom H. <to...@co...> - 2007-12-08 01:18:29
|
On Dec 8, 2007 12:50 AM, Nicholas Nethercote <nj...@cs...> wrote:
> Tom, can you try the following. In createSecVBitTable(), change the NULL
> parameter passed to OSetGen_Create to 'mycmp', and define 'mycmp' as
> follows:
>
> Word mycmp( void* key, void* elem )
> {
> Addr a1 = *(Addr*)key;
> SecVBitNode* n = (SecVBitNode*)elem;
> Addr a2 = n->a;
> if (a1 < a2) return -1;
> if (a1 > a2) return 1;
> return 0;
> }
>
> This does give the ordering that we expect for Addrs. Does the assertion
> still occur in this case?
No - that fixes the original assertion that I was seeing.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2007-12-08 01:10:18
|
In message <Pin...@mu...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Sat, 8 Dec 2007, Tom Hughes wrote:
>
> >> I think it is a problem with the fast comparison. I've reproduced the bug,
> >> and when I added an explicit slow comparison function, it behaves correctly.
> >> I'll keep looking...
> >
> > I came to that conclusion as well, but had to go out before I had a
> > chance to send another mail.
> >
> > Thinking about it as I was walking to the station I suddenly realised
> > that the fast case comparison is treating the addresses as Word types
> > which are signed, so the high address in this case becomes negative
> > and appears to come before the other address.
>
> The thing is, as long as the comparison is always done the same way, it
> should work. The ordering won't be right if we treat the values as
> unsigned addresses, but they will be right if we treat the values as signed
> words.
>
> I thought I had reproduced the bug, but all I've reproduced is the
> unexpected ordering -- I can't actually get the assertion failure on the
> lookup.
I don't get the assertion until some more stuff has been added to
the tree - the reason is that although the tree is out of order that
node is at the root and is therefore found without having to decide
which way to go.
Only once it has been pushed down from the root by adding other things
do the lookups start to fail.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2007-12-08 00:51:03
|
On Sat, 8 Dec 2007, Tom Hughes wrote:
>> I think it is a problem with the fast comparison. I've reproduced the bug,
>> and when I added an explicit slow comparison function, it behaves correctly.
>> I'll keep looking...
>
> I came to that conclusion as well, but had to go out before I had a
> chance to send another mail.
>
> Thinking about it as I was walking to the station I suddenly realised
> that the fast case comparison is treating the addresses as Word types
> which are signed, so the high address in this case becomes negative
> and appears to come before the other address.
The thing is, as long as the comparison is always done the same way, it
should work. The ordering won't be right if we treat the values as
unsigned addresses, but they will be right if we treat the values as signed
words.
I thought I had reproduced the bug, but all I've reproduced is the
unexpected ordering -- I can't actually get the assertion failure on the
lookup.
AFAICT, 'fast_cmp' and 'avl_lookup' are the only two functions that do the
fast comparisons. And they seem to be doing the same thing -- they treat
the words as signed, do a subtraction, the result is treated as signed, and
the result is checked for < 0 or > 0.
Tom, can you try the following. In createSecVBitTable(), change the NULL
parameter passed to OSetGen_Create to 'mycmp', and define 'mycmp' as
follows:
Word mycmp( void* key, void* elem )
{
Addr a1 = *(Addr*)key;
SecVBitNode* n = (SecVBitNode*)elem;
Addr a2 = n->a;
if (a1 < a2) return -1;
if (a1 > a2) return 1;
return 0;
}
This does give the ordering that we expect for Addrs. Does the assertion
still occur in this case?
Nick
|
|
From: Tom H. <to...@co...> - 2007-12-08 00:40:23
|
In message <Pin...@mu...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Fri, 7 Dec 2007, Julian Seward wrote:
>
> > I had a brief check through m_oset.c, looking for word size and signedness
> > issues to do with fast-case comparisons of keys (as is used here), but
> > saw nothing suspicious.
>
> I think it is a problem with the fast comparison. I've reproduced the bug,
> and when I added an explicit slow comparison function, it behaves correctly.
> I'll keep looking...
I came to that conclusion as well, but had to go out before I had a
chance to send another mail.
Thinking about it as I was walking to the station I suddenly realised
that the fast case comparison is treating the addresses as Word types
which are signed, so the high address in this case becomes negative
and appears to come before the other address.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|