[Zope3-dev] buildbot failure in Zope3 trunk 2.4 FreeBSD tmiddleton

[Christian Theune]

Hi,

thanks Tim, for the partial enlightenment. :) Unfortunately my 
BTree/C-wisdom is much much smaller than yours, so I got to check a 
couple of assumptions over here. :)

Tim Peters wrote:
> [Christian Theune]
>> Hah. Looks like BTrees can accept 2**31 on machines where maxint is a
>> larger ...
> 
> Note that "accept" in this case means "silently loses the
> most-significant bits", and that's a BTree bug on platforms where
> sizeof(long) > sizeof(int):
> 
>    http://www.zope.org/Collectors/Zope/1592

I was able to reproduce this on an Intel 64-Bit machine (EM64T) running 
Linux and gcc.

For one: I didn't see any compiler warnings. That sounds bad, right?

> 2**31 doesn't actually lose any bits when you store it, but it will
> probably misinterpret the high-order data bit as the sign bit when you
> fetch it again, magically changing it into -2**31.

I can store 2**31 in the BTree, but the keys() method will tell you that 
it actually stored -2**31.

>> As we hardcoded the search space to 2**31, I made the test check
>> whether btrees accept the number or not and differ in the expected 
>> results.
>> Should work on that 64bit machine now too.
> 
> Did you see my simpler suggestion for fixing the underlying bug (it
> was a one-liner change to the original code)?  When you get tired of
> fighting the 64-bit BTree bug here (it will be a minor miracle if the
> test actually passes now on a 64-bit box, despite all you've tried
> ...), look that up ;-)

Nope, I didn't find your one-liner. :) Can you post it explicitly for my 
blind eyes?

I think I could have made up something that made it work, but I started 
looking into making the BTree behave sanely.

My idea was, to modify the BTree code in a way that it actually checks 
after the type cast whether the casted value is equal to the requested 
key, or alternatively try making the CHECK_KEY macro do an "exact type 
match" instead of allowing subclasses. But that wouldn't work either as 
2**31 is still an int on those platforms. I'm a bit puzzled now. :)

Christian

-- 
gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany
www.gocept.com - ct at gocept.com - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development