[issue25083] Python can sometimes create incorrect .pyc files

[STINNER Victor]

Change by STINNER Victor :


--
components: +Interpreter Core

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[STINNER Victor]

Change by STINNER Victor :


--
resolution:  -> fixed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[Petr Viktorin]

Change by Petr Viktorin :


--
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[Petr Viktorin]

Petr Viktorin  added the comment:


New changeset f64c813de84011a84ca21d75a294861a9cc2dfdc by Petr Viktorin 
(tzickel) in branch '2.7':
bpo-25083: Python can sometimes create incorrect .pyc files (GH-8449)
https://github.com/python/cpython/commit/f64c813de84011a84ca21d75a294861a9cc2dfdc


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[Brett Cannon]

Change by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[tzickel]

Change by tzickel :


--
pull_requests: +7971
stage:  -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[STINNER Victor]

Change by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[Petr Viktorin]

Petr Viktorin  added the comment:

tzickel, could you sign the CLA? It will formally allow PSF to distribute your 
patch with Python. (You retain the copyright.) See the dev guide for 
instructions: https://docs.python.org/devguide/pullrequest.html#cla

I can't do that for you, but if you want, I can do the rest (open a pull 
request and convince some core developer to merge it) after you sign the CLA.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[Nick Coghlan]

Nick Coghlan  added the comment:

Adding a couple of Red Hat folks to the nosy list, as even though this was 
originally reported for Windows, the reproducers show that it's a 
cross-platform issue.

tzickel would you mind signing the Python CLA and turning your patch into a PR 
on Github?

--
nosy: +cstratak, encukou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[Gregory P. Smith]

Gregory P. Smith  added the comment:

I'm un-cc'ing myself as I don't use Python 2 in an environment where we allow 
it to write .pyc files at application runtime.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[Gregory P. Smith]

Change by Gregory P. Smith :


--
nosy:  -gregory.p.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[tzickel]

tzickel  added the comment:

Added a script to check if the bug exists (provided you have an updated strace 
4.15 or above).

Without patch:
# ./import_io_check.sh
strace: Requested path 'tmp.py' resolved into '/root/tmp.py'
read(3, 0x55fc3a71cc50, 4096)   = -1 ENOSYS (Function not implemented) 
(INJECTED)
read(3, 0x55fc3a71cc50, 4096)   = -1 ENOSYS (Function not implemented) 
(INJECTED)
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named py
+++ exited with 1 +++
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named py
Bug exists an incorrect .pyc has been produced

With patch:
# PYTHON=Python-2.7.14-with-patch/python ./import_io_check.sh
strace: Requested path 'tmp.py' resolved into '/root/tmp.py'
read(3, 0x55a8ff7d3020, 4096)   = -1 ENOSYS (Function not implemented) 
(INJECTED)
read(3, 0x55a8ff7d3020, 4096)   = -1 ENOSYS (Function not implemented) 
(INJECTED)
Traceback (most recent call last):
  File "", line 1, in 
  File "tmp.py", line 1

^
SyntaxError: unexpected EOF while parsing
+++ exited with 1 +++
Script finished successfully

--
nosy: +brett.cannon
Added file: https://bugs.python.org/file47229/import_io_check.sh

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[tzickel]

tzickel  added the comment:

Ignore the hash append / link at the start of each shell command (it's the 
output from docker, and not related to python commits).

BTW, forgot to mention, of course when doing the fault injection on the .py 
files, the error is bad as well, it should be I/O error, and instead it shows 
that it's an empty module:
AttributeError: 'module' object has no attribute 'parse'

(The patch actually fixes that).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[tzickel]

tzickel  added the comment:

OK, This issue has been biting me a few more times in production, so for now 
I've added the environment variable PYTHONDONTWRITEBYTECODE which resolves it 
(but it's a hack). I'm sure I am not the only one with it (recall that this is 
happening in a complex setup where I run python in windows via a network drive 
hosted in netapp, and runs thousands of times from many machines).

So, I've been looking for a simple way to show you it's a major fault at the 
python 2 import I/O error checking, and found that new strace has fault 
injection capability :)

In this demo I'll be running under debian sid (has strace version high enough 
for fault injection and latest python 2), you can use docker if you don't have 
it.

On my mac, I'm running (this example is on one of python's init modules, but of 
course can happen on any .py file):

user$ docker run -it --cap-add SYS_PTRACE debian:sid

The cap-add is needed for strace to run.

root@2dcc36934ea6:/# apt-get update && apt-get install -y strace python

root@2dcc36934ea6:/# python
Python 2.7.14 (default, Sep 17 2017, 18:50:44)
[GCC 7.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> exit()

Python works just fine.

root@2dcc36934ea6:/# strace -P /usr/lib/python2.7/sre_parse.pyc -P 
/usr/lib/python2.7/sre_parse.py -e trace=read -e fault=read python
read(7, 0x55c3ac2ad900, 4096)   = -1 EPERM (Operation not permitted) 
(INJECTED)
...
read(6, 0x55c3ac2cb680, 4096)   = -1 EPERM (Operation not permitted) 
(INJECTED)
...
Traceback (most recent call last):
  File "/usr/lib/python2.7/site.py", line 554, in 
main()
...
  File "/usr/lib/python2.7/sre_compile.py", line 572, in compile
p = sre_parse.parse(p, flags)
AttributeError: 'module' object has no attribute 'parse'
+++ exited with 1 +++

This command simply causes the python process to fail the read command on the 
files sre_parse.py and sre_parse.pyc (the .pyc btw already existed from 
previous run).
This should be OK, since it can't read a required module form disk.

root@2dcc36934ea6:/# python
Traceback (most recent call last):
  File "/usr/lib/python2.7/site.py", line 554, in 
main()
...
  File "/usr/lib/python2.7/sre_compile.py", line 572, in compile
p = sre_parse.parse(p, flags)
AttributeError: 'module' object has no attribute 'parse'

This is already bad, python does not work anymore, now even without an I/O 
error :(

root@2dcc36934ea6:/# ls -l /usr/lib/python2.7/sre_parse.pyc
-rw-r--r-- 1 root root 118 Oct 21 09:20 /usr/lib/python2.7/sre_parse.pyc

If we check, we see that the previous python instance with I/O error created an 
empty byte code valid sre_parse.pyc (you can check it by dis.dis it, and see 
it's empty code object), this is the crux of the bug.

root@2dcc36934ea6:/# rm /usr/lib/python2.7/sre_parse.pyc

let's delete the bad .pyc file

root@2dcc36934ea6:/# python
Python 2.7.14 (default, Sep 17 2017, 18:50:44)
[GCC 7.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> exit()

yey, python works now again

root@2dcc36934ea6:/# ls -l /usr/lib/python2.7/sre_parse.pyc
-rw-r--r-- 1 root root 21084 Oct 21 09:20 /usr/lib/python2.7/sre_parse.pyc

We can see now that the .pyc file has a much bigger size (21084 bytes compared 
to 118 from before)

root@2dcc36934ea6:/# strace -P /usr/lib/python2.7/sre_parse.pyc -P 
/usr/lib/python2.7/sre_parse.py -e trace=read -e fault=read python -B
read(7, 0x55ceb72a7900, 4096)   = -1 EPERM (Operation not permitted) 
(INJECTED)
...
read(6, 0x55ceb72c5680, 4096)   = -1 EPERM (Operation not permitted) 
(INJECTED)
...
Traceback (most recent call last):
  File "/usr/lib/python2.7/site.py", line 554, in 
main()
...
AttributeError: 'module' object has no attribute 'parse'
+++ exited with 1 +++

We can now try this issue with python -B which should not try to create .pyc 
files

root@2dcc36934ea6:/# python
Python 2.7.14 (default, Sep 17 2017, 18:50:44)
[GCC 7.2.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> exit()

yey, python still works (hopefully if this is an network I/O error, it will 
stop occurring on a future run with a watchdog for an server app)


A less likely variant (but possible) is that if the .pyc does not exist, and 
you have an I/O error on importing the .py, it will produce an bad .pyc file, 
you can try it:
root@2dcc36934ea6:/# rm /usr/lib/python2.7/sre_parse.pyc
root@2dcc36934ea6:/# strace -P /usr/lib/python2.7/sre_parse.py -e trace=read -e 
fault=read python
root@2dcc36934ea6:/# python
Python will not work until you delete the .pyc file.



(*) The I/O error needs to occur when the AST parser will still produce a valid 
code object, this easily happens when the error is just when starting to read 
the file (will produce an empty code AST which will create an 

[issue25083] Python can sometimes create incorrect .pyc files

[tzickel]

tzickel added the comment:

Sorry Brett of course I meant the upcoming 2.7.12 

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[Brett Cannon]

Changes by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[Brett Cannon]

Brett Cannon added the comment:

Python 2.6 is no longer supported.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[tzickel]

tzickel added the comment:

any chance for 2.6.12 ? 4 line patch.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[tzickel]

Changes by tzickel :


--
nosy: +serhiy.storchaka

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[Brett Cannon]

Brett Cannon added the comment:

As I said previously, tzickel, this is an edge case in Python 2.7 which means 
it has a low priority for most core developers. Realize that we are also 
working towards a Python 3.5.1 release and a 3.4.4 release as well (which will 
be the first and last bugfix release for those feature releases, respectively). 
Compare that to Python 2.7 which probably has 10 more bugfix releases and where 
this issue has now existed for five years and this is the first report for it, 
meaning we are not rushing to get it done with other pressing issues to work on.

I realize it's serious to *you*, but that unfortunately doesn't translate it to 
it being as important to everyone else so please be patient. If this is still 
an issue for you then consider deleting all of your .pyc files and switching 
off bytecode file generation: 
https://docs.python.org/2/library/sys.html#sys.dont_write_bytecode .

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[tzickel]

tzickel added the comment:

Meador Inge any other questions regarding the issue ? I can't believe 2.7.11 is 
coming out soon, and nobody is taking this issue seriously enough...

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[tzickel]

tzickel added the comment:

1. You are correct the issue I am talking about is in parsing source files 
(Altough because python caches them as .pyc it's a worse situation).
2. The example you give is EINTR handling (which is mostly handling interrupted 
I/O operations by signals and retrying them) the real I/O error checking in 
that get_line is I belive in the next ferror check there. It might be nice to 
have EINTR checking (and retry) when reading the source file as well, but that 
is a secondary issue.
3. As for your recommendation for changing Py_UniversalNewlineFgets, you can 
see that both it's documentation says "Note that we need no error handling: 
fgets() treats error and eof identically." and since it seems like a low-level 
function that does not have any python stuff like exception handling, and in 
it's current signature it can't return an error (it simply returns the buffer, 
or NULL if nothing was read).
4. As for why putting it in that position, basically there could be a few I/O 
paths, besides Py_UniversalNewlineFget, such as codec decoding in fp_readl (via 
decoding_fgets) that can fail in I/O as well. Looking at the code again (while 
not tested), maybe the check can be actually moved to the end of decoding_fgets 
in tokenizer.c i.e. if there is an ferror in tok->fp in the end of 
decoding_fgets then to return error_ret(tok); there, but then double eyes need 
to be sure that no other code path can have an I/O error. I am not an expert on 
the layout of tokenizer (read it mostly to figure out this bug) so if that's 
better it can be moved I guess.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[Brett Cannon]

Brett Cannon added the comment:

Nope, I think you probably have everyone who might be interested in looking at 
fixing this on the issue, tzickel. Just a matter of someone taking the interest 
and initiative to fix this in Python 2.7.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[tzickel]

tzickel added the comment:

TL:DR
Python 2 forgot to do I/O error checking when reading .py files from disk. On 
some rare situations this can bite Python in the ass and cause it to bork .pyc 
files.

Checked python 3, it checks the I/O in a different / better way.

Next python 2.7 is out in 1.5 month, I really want this fix to get in, did I 
forgot to nose some developer who can help out ?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[Meador Inge]

Meador Inge added the comment:

I started poking at the patch a little and have a few comments.

My understanding of the issue comments is that the read error actually happens 
when reading in the *source* file and *not* the bytecode file.  This happens 
because 'ferror' is not checked after receiving an EOF and thus we think we 
just have an empty source file.  I can understand how creating a reproducible 
test case for this error path would be very difficult.

So, checking for errors with 'ferror' definitely seems reasonable, but why do 
it in the tokenizer code?  I already see several places in 'fileobject.c' that 
do similar checks.  For example, in 'get_line' I see:

   while ( buf != end && (c = GETC(fp)) != EOF ) {
  ...
   }
   if (c == EOF) {
  if (ferror(fp) && errno == EINTR) {
 ...
  }
   }

As such, wouldn't handling this error case directly in 
'Py_UniversalNewlineFgets' similar to the above code be more appropriate?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[Brett Cannon]

Brett Cannon added the comment:

I have not looked at your patch, tzickel, but I just wanted to let you know a 
lack of reply just means lack of time on the part of the core developers. We 
are all volunteers and essentially don't get paid to spend our time to work on 
Python. Add in the fact that this is an odd edge case issue on Python 2.7 and 
that lowers the priority for someone to get to it when there are more pressing 
issues related to the new 3.5.0 release.

Hopefully someone who has a good understanding of the low-level C details you 
are talking about in your patch will be able to make a good judgment as to 
whether the test case and patch make sense.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[tzickel]

tzickel added the comment:

Not sure why nobody has responded yet, but I have gone up and made a patch for 
the problem for 2.7 HEAD. Would be great if someone with more understanding of 
python's source could say if this is the optimal place to do the ferror test.

I am able to see that this patch fixes the issue (now the import fails on EOF 
with an error instead of producing an empty valid AST and an empty code object 
.pyc file)

Unfortunately testing that the patch fixes the issue, currently involves 
LD_PRELOADing an dynamic library which hooks __srget (because thats what the 
getc macro in Py_UniversalNewlineFgets uses in posix systems) to return EOF, 
and ferror to return a non zero result:

If the code for the hooking dynamic library is needed, please tell me (I can't 
figure out how to make an automated test for it).

-

shell$ cat a.py
print 'hi'

Before fixing python:

shell$ ls a.py*
a.py
shell$ DYLD_FORCE_FLAT_NAMESPACE=1 DYLD_INSERT_LIBRARIES=libblah.dylib python
Python 2.7.10 (default, Jul 13 2015, 12:05:58)
[GCC 4.2.1 Compatible Apple LLVM 6.1.0 (clang-602.0.53)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.environ['BORK_IO_TEST'] = 'a' # this activates the EOF / ferror
>>> import a # this should print 'hi' or fail but does not...
>>> a

>>> exit()
shell$ ls a.py*
a.py   a.pyc

You can see that it accepted a.py as an empty file and a bad a.pyc was created.

After the patch:
shell$ ls a.py*
a.py

shell$ DYLD_FORCE_FLAT_NAMESPACE=1 DYLD_INSERT_LIBRARIES=libblah.dylib 
./python.exe
Python 2.7.10+ (2.7:f6125114b55f+, Sep 18 2015, 19:18:34)
[GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.72)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.environ['BORK_IO_TEST'] = 'a'
>>> import a
Traceback (most recent call last):
  File "", line 1, in 
  File "a.py", line 1

^
SyntaxError: unexpected EOF while parsing
>>> a
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'a' is not defined
>>> exit()
shell$ ls a.py*
a.py

Now the import failed, and of course no empty code .pyc file was created.

--
keywords: +patch
nosy: +benjamin.peterson
Added file: http://bugs.python.org/file40505/ferror_check_in_tokenizer.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[tzickel]

tzickel added the comment:

As for the "example" .pyc just create an empty 0 byte .py file and compile it, 
that is the same .pyc that is created in my system (instead in my case the .py 
is not empty).

Just so people don't have to trace the code like I did, here is the traceback 
of the primary issue. Remember that my hypothesis is that fopen returns an FILE 
stream, that returns EOF on the first get because of an I/O error, not because 
the file is empty:

--> GETC is called, and gets EOF on the first try, and thus 
Py_UniversalNewlineFgets returns NULL
  * frame #0: 0x000109fe4c44 Python`Py_UniversalNewlineFgets
frame #1: 0x000109fc972c Python`decoding_fgets + 321
frame #2: 0x000109fc9262 Python`tok_nextc + 918
frame #3: 0x000109fc830e Python`PyTokenizer_Get + 171
frame #4: 0x000109fc5853 Python`parsetok + 128
frame #5: 0x00010a066748 Python`PyParser_ASTFromFile + 109
-> Now load_source_module has an empty AST which will get compiled to an empty 
code module
-> this code is optmized so we don't see the parse_source_module call
here, but write_compiled_module will be called afterwards with the empty
AST tree instead of aborting...
frame #6: 0x00010a05e3b5 Python`load_source_module + 671
frame #7: 0x00010a05f003 Python`import_submodule + 270
frame #8: 0x00010a05ebc6 Python`load_next + 284
frame #9: 0x00010a05cb5d Python`PyImport_ImportModuleLevel + 453
frame #10: 0x00010a042641 Python`builtin___import__ + 135


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[tzickel]

tzickel added the comment:

You are not looking at the correct code, the function you are pointing to, 
check_compiled_module is run to check the existing .pyc (it is a good question, 
why the .pyc is overriden, but that is a secondary issue, which I cannot 
reproduce as I've said by demand).

I am talking about the code which creates a new (and incorrect) .pyc in 
parse_source_module:
https://hg.python.org/cpython/file/2.7/Python/import.c#l861
calls in the end to Py_UniversalNewlineFgets
https://hg.python.org/cpython/file/2.7/Objects/fileobject.c#l2749
you can see that function will return NULL if it gets an EOF because of a file 
error, and then the tokenises which calls it will not know if it got NULL 
because of EOF or file error, and compile the AST and generate an incorrect 
.pyc file.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[tzickel]

Changes by tzickel :


--
nosy: +brett.cannon, meador.inge

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[Gregory P. Smith]

Gregory P. Smith added the comment:

we'll need a test case .pyc where this happens.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue25083] Python can sometimes create incorrect .pyc files

[Gregory P. Smith]

Gregory P. Smith added the comment:

Inspecting the 2.7 code:

https://hg.python.org/cpython/file/2.7/Python/import.c#l761
following that down to 
https://hg.python.org/cpython/file/2.7/Python/marshal.c#l1126

it looks like it does the right thing on EOF error (from either getc or from 
fread) and raises an exception which aborts load_compiled_module.

--
nosy: +gregory.p.smith

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com