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.
> > Thi
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
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
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
> > Fedora 8!
>
> This probably sounds like a really dumbass question, but .. do the two
> machines have the same CPUs? I ask because just recently Christoph
> Bartoschek (IIRC) reported some strangeness to do with memory
> corruption and CPUs. Or something. Christoph, can you
Am Mittwoch, 5. Dezember 2007 schrieb Julian Seward:
> On Wednesday 05 December 2007 16:32, Christoph Bartoschek wrote:
> > The read of COND in the parent thread happens in a segment that is after
> > the accesses that established the shared-modified state in the
> >
Am Samstag, 27. Oktober 2007 schrieb Julian Seward:
> > thanks for your work on a helgrind replacement. Such a tool is a great
> > help for us.
>
> Thanks for the feedback and test program. What version of glibc do
> your test machines have?
Both machines are opensuse 10.2
i386: GNU C Library sta
Hi,
thanks for your work on a helgrind replacement. Such a tool is a great help
for us.
I have tested thrcheck from revision 7044 with the attached program. Here are
some problems I found:
1. The concurrent writes on line 72 are not protected by a mutex (uncommented
above and below). Thrcheck
