On May 16, 2013, at 02:19 PM, Guido van Rossum wrote: >Now consider the following scenario. It involves *three* processes. > >- Two unrelated processes both start and want to import the same module. >- They both see the .pyc file is missing/corrupt and decide to write it. >- The first process finishing writing the file, writing the correct header. >- Now a third process wants to import the module, sees the valid >header, and starts reading the file. >- However, while this is going on, the second process gets ready to >write the file. >- The second process truncates the file, writes the dummy header, and >then stalls. >- At this point the third process (which thought it was reading a >valid file) sees an unexpected EOF because the file has been >truncated. > >Now, this would explain the EOFError, but not necessarily the >ValueError with "unknown type code". However, it looks like marshal >doesn't always check for EOF immediately (sometimes it calls getc() >without checking the result, and sometimes it doesn't check the error >state after calling r_string()), so I think all the errors are >actually explainable from this scenario.
Thanks for this, it's a very interesting scenario. I think this isn't a complete explanation of what's going on though. I've spoken with our defect analyst and looked at a bunch of the bug reports, and as far as we can tell, the corruptions are permanent. Users generally have to take manual action to delete the .pyc files and re-create them. One thing I hadn't realized until now is that until Python 3.4, py_compile.py doesn't write the pyc files atomically, and in fact this is the mechanism we're using to create the pyc files at package installation time. That could explain why we're still seeing these issues even in Python 3.3. I've also uncovered a bug from 2010 reported in Debian[1] about pyc file corruptions that happened when the byte-compilation driver program exited before its workers[2] could complete. We're definitely seeing issues post-landing of this fix, so I need to do some more analysis to see if that fix was enough. If it wasn't, and we're not doing atomic renames, than that could explain the permanent corruptions. Cheers, -Barry [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=590224 [2] the workers each call calling `$PYTHON -m py_compile - < py-filenames`
signature.asc
Description: PGP signature
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
