[Python-Dev] RE: test_sort.py failure

Tim Peters tim.peters at gmail.com
Thu Jul 29 06:54:41 CEST 2004


[Delaney, Timothy C (Timothy)]
> Might it be worthwhile trying to capture *one* starting point that
> provokes this behaviour consistently on some machines and include that
> as an additional specific test case?

Fine by me if someone else can do that (it never failed on my box no
matter how I fiddled with it -- but it certainly *could* have failed
on my box before "in theory").

> I guess it would depend on how consistently it could be provoked.

That's the rub -- it depends on whether the system realloc() manages
(in the pre-patch code) to extend the initial empty_ob_item thingie
in-place, and do all subsequent extends in-place too.  The overall
odds should be better the shorter the initial list (> 1), but it still
depends on the system realloc(), and almost certainly depends too on
the state of the C malloc heap at the time the test begins.

The initial malloc request was for 1 byte, and I think There's A
Reason the MS realloc() can never extend its result for that in-place
when a non-silly number of bytes is requested (as an actual allocation
requires).  The same would be true if we had been using PyMalloc to
allocate empty_ob_item (i.e., PyMalloc could not extend it in-place
either).


More information about the Python-Dev mailing list