[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