Python 2.2 __slots__ Bug?

[Bengt Richter]

On Wed, 26 Jun 2002 10:23:45 -0500 (CDT), Glyph Lefkowitz <glyph at twistedmatrix.com> wrote:

>----Security_Multipart(Wed_Jun_26_10:23:45_2002_363)--
>Content-Type: Text/Plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>
>From: Jonathan Hogg <jonathan at onegoodidea.com>
>Subject: Re: Python 2.2 __slots__ Bug?
>Date: Wed, 26 Jun 2002 14:00:48 +0100
>
>> On 26/6/2002 12:03, in article
>> mailman.1025089474.17780.python-list at python.org, "Glyph Lefkowitz"
>> <glyph at twistedmatrix.com> wrote:
>> 
>> > I get "I'm fine" and then a segmentation fault.  This only happens when
>> > __slots__ is defined on a new-style class.  Seriously, i'm not making those
>> > numbers up -- reliably, 43551 objects will crash the interpreter; fewer will
>> > not.
>> 
>> Interestingly I get the construction working fine, but the 'del' crashes the
>> interpreter with (on Mac OS X):
>
>Hmm.  Sprinkling print statements about shows it dying on the 'del' (this is
>how I encountered the bug originally, I was trying to time the [de]allocation
>of large numbers of objects under 2.1 vs. 2.2), but the stacktrace is still the
>same; is there some difference between the way allocation works on OS X
>vs. Linux? (I assume if you can run OS X we're using the same hardware.)
>
>> This seems to fail for me at 5430 objects. I couldn't get the allocation to
>> crash at all (or at least up to a million objects, after which I got bored).
>
>Yep, same here.  Allocation is no problem.
>
Wondering if there's any 12*n byte chunks involved, fitting
into some 2**n (-overhead) allocation space? Just noticing

 >>> divmod(2**19, 43551)
 (12, 1676)
 >>> divmod(2**16, 5430)
 (12, 376)

Sometimes these things mean something, sometimes they don't ;-)
Maybe it will jog someone's thought. E.g., a last-item index/limit
problem?

Regards,
Bengt Richter