[Python-Dev] Non-stable pyc results on python 3.6 (original) (raw)

Nick Coghlan ncoghlan at gmail.com
Thu Jul 27 10:54:19 EDT 2017

On 27 July 2017 at 23:48, jan matejek <jmatejek at suse.cz> wrote:

This is most often found in init.py. Often this affects optimized pycs, but we can see it in un-optimized as well. The issue is rare -- 99% of all pycs are stable -- but when it occurs, it's easy to replicate it in the same place. This also happens on different machines, so that seems to rule out hardware memory errors :)

The marshal implementation received some significant optimisations in 3.5 [1] and a new marshal format in 3.4 [2], so if you're able to check the behaviour in 3.4 and 3.5 that would be helpful: if the problem occurs in 3.5, but not in 3.4, the hashtable based optimisations would be the place to start looking, while if 3.4 misbehaves as well, then there may be some general inconsistency to resolve in how the module decides which instances to mark with FLAG_REF.

The fact that disorderfs makes a difference does make me a little suspicious, as there's an early exit from the FLAG_REF setting code related to objects having exactly one live reference. Courtesy of string interning and other immutable object caches, order of code compilation can affect how many live references there are to strings and other constants, and hence there may be cases where marshal won't flag an immutable object if only that particular code object has been compiled, but will flag it if some other code object has been created first. That check has been there since version 3 of the marshal format was defined, so if it is the culprit, then you'll see this misbehaviour with 3.4 as well.

Cheers, Nick.

[1] https://docs.python.org/3/whatsnew/3.5.html#optimizations [2] https://github.com/python/cpython/commit/d7009c69136a3809282804f460902ab42e9972f6

-- Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

More information about the Python-Dev mailing list