[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).
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4