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.
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 ..
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 ...
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 ..
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
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
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 ... f
> 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.
--
> 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 establish
On Dec 8, 2007 12:50 AM, Nicholas Nethercote <[EMAIL PROTECTED]> 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*
In message <[EMAIL PROTECTED]>
Nicholas Nethercote <[EMAIL PROTECTED]> 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
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
> cha
In message <[EMAIL PROTECTED]>
Nicholas Nethercote <[EMAIL PROTECTED]> 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 no
> I think it is a problem with the fast comparison.
> I've reproduced the bug,
Coolness. How did you manage that?
J
-
SF.Net email is sponsored by:
Check out the new SourceForge.net Marketplace.
It's the best place to buy
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
> I've now made set_sec_vbits8 dump the tree before and after setting
> the line and it looks very simple:
>
> 0xFEC7CD30
> 0xFEC7CD70
> --11681-- setting line 0x75D0EA0
> 0xFEC7CD30
> 0xFEC7CD70
> 0x75D0EA0
>
> So we have a tree with 2 notes, insert a third and get an unordered tree
> out.
Shees
On Dec 7, 2007 3:01 PM, Tom Hughes <[EMAIL PROTECTED]> wrote:
> It seems that the problem is that the AVL tree is getting out of
> order. I made get_sec_vbits8 walk the oset when it detects the problem
> and dump the addresses to the log and this is what I get:
>
> 0x28D448D0
> 0x28D44950
> ...
>
On Dec 7, 2007 2:06 PM, Tom Hughes <[EMAIL PROTECTED]> wrote:
> On Dec 7, 2007 12:53 AM, Julian Seward <[EMAIL PROTECTED]> wrote:
>
> > That means, either:
> >
> > 1. no entry was ever made for "a"
> >(really, for VG_ROUNDDN(a, BYTES_PER_SEC_VBIT_NODE)), or
> >
> > 2. there was an entry, but i
Am Freitag, 7. Dezember 2007 schrieb Tom Hughes:
>
> Done that, and it looks like it is being created - first we get this:
>
> --31740-- setting line 0x75D0EA0
>
> and then a bit later this:
>
> Memcheck: mc_main.c:959 (get_sec_vbits8): Assertion 'n' failed.
> Memcheck: get_sec_vbits8: no no
On Dec 7, 2007 12:53 AM, Julian Seward <[EMAIL PROTECTED]> wrote:
> That means, either:
>
> 1. no entry was ever made for "a"
>(really, for VG_ROUNDDN(a, BYTES_PER_SEC_VBIT_NODE)), or
>
> 2. there was an entry, but it has since been deleted, or
>
> 3. some other snafu.
>
> Let's chase (1) firs
On Thursday 06 December 2007 09:53, Konstantin Serebryany wrote:
> I've modified my test (attached, q2.cc), hope it will be helpful :)
> It now has N worker threads. If N >= 2 the race is reported even for GLOB1.
Last night's patch (happens-before-cvhack.patch) also makes this, q2.cc,
run withou
>> Last night's patch (happens-before-cvhack.patch) also makes this, q2.cc,
>> run without race warnings.
Amazing! --happens-before=cvhack does help with this patch!
>From the comments it does look 'insanely inefficient', but it's better than
nothing. :)
I'll try other tests with cond vars.
>> A
22 matches
Mail list logo
