This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tzickel
Recipients tzickel
Date 2015-09-13.11:26:12
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za>
In-reply-to
Content
I had a non-reproducible issue occur a few times in which python 2.7.9 would produce .pyc files with empty code objects on a network drive under windows. The .pyc might have been created due to intermittent network errors that are hard to reproduce reliably. The .pyc files would override the previous correct .pyc files that existed in the same place.

The incorrect .pyc is a valid file, but instead of having the code object of the original .py file compiled, it would have the code object of an empty .py file. Python would then go on to use the incorrect .pyc file until it is manually deleted.

This peculiar .pyc files got me thinking about how cpython can produce such an incorrect .pyc file instead of failing.

The main issue here is that getc function, returns EOF both on EOF and on file error. It seems as if the tokenizer starts reading the file stream, and gets an EOF directly, it would not check if it resulted from actually reading an empty file or because of an file error, and happily return an empty AST which would be then compiled to a bad empty code .pyc instead of aborting the process because of an file error.
History
Date User Action Args
2015-09-13 11:26:12tzickelsetrecipients: + tzickel
2015-09-13 11:26:12tzickelsetmessageid: <1442143572.78.0.211523310189.issue25083@psf.upfronthosting.co.za>
2015-09-13 11:26:12tzickellinkissue25083 messages
2015-09-13 11:26:12tzickelcreate