EOFError: marshal data too short -- causes?

[Glenn Linderman]

On 12/28/2015 11:19 PM, Terry Reedy wrote:
> On 12/29/2015 1:50 AM, Glenn Linderman wrote:
>> Here's a sanatized stack trace off my web server:
>>
>>    File ".../cgihelpers.py", line 10, in
>>      import cgitb
>>    File ".../py34/lib/python3.4/cgitb.py", line 24, in
>>      import inspect
>>    File ".../py34/lib/python3.4/inspect.py", line 54, in
>>      from dis import COMPILER_FLAG_NAMES as _flag_names
>>    File "", line 2237, in _find_and_load
>>    File "", line 2226, in _find_and_load_unlocked
>>    File "", line 1200, in _load_unlocked
>>    File "", line 1129, in _exec
>>    File "", line 1467, in exec_module
>>    File "", line 1570, in get_code
>>    File "", line 656, in _compile_bytecode
>> EOFError: marshal data too short
>>
>>
>> It worked this morning, and does this now.  I hadn't changed anything.
>
> Since it crashes trying to unmarshal compiled dis bytecode, I would 
> assume that the .pyc file is corrupted and remove it. Based on the 
> above, it should be in
> .../py34/lib/python3.4/__pycache__/dis.*.pyc
> Python will then recompile dis and write a new .pyc file.
>

Thank you, thank you, thank you, thank you, thank you, thank you, thank 
you, thank you, thank you, thank you, thank you, thank you, thank you, 
thank you, thank you, thank you, thank you, thank you, thank you, thank 
you, thank you, thank you, thank you, thank you, thank you, thank you, 
thank you, thank you, thank you, thank you, thank you, thank you, thank 
you, thank you, thank you, thank you, thank you, thank you, thank you, 
thank you!

The site is working now, again.  Thank you, again.

Because of the File "" lines, and the fact that there were recent 
comments about frozen import stuff on python-dev, I was thinking that 
the corruption was at a lower level, and never thought to zap a .pyc.

OK, so I actually renamed it instead of zapping it.  Them, actually, 
there were both .pyc and .pyo.

Now the __pycache__ directory is full of .pyc and .pyo files (from the 
install? On April 19th? (the date on most of the files).  But:

areliabl at areliabledomain.com [~/py34/lib/python3.4/__pycache__]# ll dis*
-rw-r--r-- 1 areliabl areliabl 14588 Dec 29 00:27 dis.cpython-34.pyc
-rw-r--r-- 1 areliabl areliabl  8192 Dec 28 19:16 dis.cpython-34.pyc-xxx
-rw-r--r-- 1 areliabl areliabl 14588 Apr 19  2015 dis.cpython-34.pyo-xxx

(I renamed the existing .py* files by appending -xxx).

So we can see that somehow, today at 19:16 (probably UTC) the dis.*.pyc 
file got chopped to 8192 bytes. That's a suspicious number, being a 
power of 2... but... I haven't updated Python since originally 
installing it on the web server, on April 19th.  So why would _that_ 
.pyc file have today's date? Because of UTC, the replacement has 
tomorrow's date :)  But it seems like it should have had Apr 19 2015 
like all the rest.

Except, all the rest don't have Apr 19 2015... most of them do, but 
there are a fair number from today, and a couple from Dec 15 (listed 
below).  I don't quickly see any others that are suspiciously exactly a 
power of 2!

But, under the assumption that the install created all these files in 
the first place, why would _any_ of them have newer dates?  I haven't 
gone around deleting any .pyc files since April.  And if they are 
already there, why would Python rebuild them? Isn't the point of the 
.pyc files to not need to recompile?  And even if the original build 
didn't build them, since I haven't touch the python sources on this web 
server for months, shouldn't all the files be months old, at least?

And isn't it rather suspicious that of the ones that are rebuilt, that 
all of them have exactly the same timestamp, rather than being sprinkled 
around with different dates?  Well, the two from Dec 15 have the same 
time, and all the ones from today have the same time. But that doesn't 
seem like some sort of "random error or access conflict accessing file 
causing it to be rebuilt"....

Should I accuse my web host of playing with these files?  Are they 
backing up/restoring?  Are they simply touching the files? Is their 
infrastructure flaky such that whole groups of files get deleted now and 
then (and either rebuilt or restored with a different date)?


areliabl at areliabledomain.com [~/py34/lib/python3.4/__pycache__]# find 
-mtime -240 -ls
113654924   20 drwxr-xr-x   2 areliabl areliabl    20480 Dec 29 00:27 .
113639463   76 -rw-r--r--   1 areliabl areliabl    76650 Dec 28 19:16 
./inspect.cpython-34.pyc
113639477   16 -rw-r--r--   1 areliabl areliabl    14588 Dec 29 00:27 
./dis.cpython-34.pyc
113639458   16 -rw-r--r--   1 areliabl areliabl    12361 Dec 28 19:16 
./ast.cpython-34.pyc
113639451   36 -rw-r--r--   1 areliabl areliabl    32773 Dec 28 19:16 
./shutil.cpython-34.pyc
113639468   12 -rw-r--r--   1 areliabl areliabl    10371 Dec 28 19:16 
./contextlib.cpython-34.pyc
113639469   16 -rw-r--r--   1 areliabl areliabl    15916 Dec 28 19:16 
./lzma.cpython-34.pyc
113639475   16 -rw-r--r--   1 areliabl areliabl    15130 Dec 28 19:16 
./bz2.cpython-34.pyc
113639486   68 -rw-r--r--   1 areliabl areliabl    67747 Dec 28 19:16 
./tarfile.cpython-34.pyc
113639479   68 -rw-r--r--   1 areliabl areliabl    65875 Dec 28 19:16 
./argparse.cpython-34.pyc
113639459   48 -rw-r--r--   1 areliabl areliabl    45794 Dec 28 19:16 
./zipfile.cpython-34.pyc
113639484   32 -rw-r--r--   1 areliabl areliabl    31374 Dec 28 19:16 
./platform.cpython-34.pyc
113639450    8 -rw-r--r--   1 areliabl areliabl     4608 Dec 15 03:01 
./copyreg.cpython-34.pyc
113639474   16 -rw-r--r--   1 areliabl areliabl    13665 Dec 28 19:16 
./textwrap.cpython-34.pyc
113639454   44 -rw-r--r--   1 areliabl areliabl    43428 Dec 28 19:16 
./subprocess.cpython-34.pyc
113639452   40 -rw-r--r--   1 areliabl areliabl    39051 Dec 15 03:01 
./threading.cpython-34.pyc
113639472   16 -rw-r--r--   1 areliabl areliabl    12721 Dec 28 19:16 
./gettext.cpython-34.pyc
113639470    8 -rw-r--r--   1 areliabl areliabl     8060 Dec 28 19:16 
./copy.cpython-34.pyc
113639467    8 -rw-r--r--   1 areliabl areliabl     6370 Dec 28 19:16 
./hashlib.cpython-34.pyc
113639483   12 -rw-r--r--   1 areliabl areliabl    11461 Dec 28 19:16 
./pprint.cpython-34.pyc
113639460    8 -rw-r--r--   1 areliabl areliabl     7871 Dec 28 19:16 
./string.cpython-34.pyc
113639478   32 -rw-r--r--   1 areliabl areliabl    29697 Dec 28 19:16 
./cgi.cpython-34.pyc
113639464   20 -rw-r--r--   1 areliabl areliabl    17601 Dec 28 19:16 
./pkgutil.cpython-34.pyc
113639453    8 -rw-r--r--   1 areliabl areliabl     6437 Dec 28 19:16 
./quopri.cpython-34.pyc
113639476    8 -rw-r--r--   1 areliabl areliabl     8192 Dec 28 19:16 
./dis.cpython-34.pyc-xxx
113639466   92 -rw-r--r--   1 areliabl areliabl    90383 Dec 28 19:16 
./pydoc.cpython-34.pyc
113639461   12 -rw-r--r--   1 areliabl areliabl     8466 Dec 28 19:16 
./_weakrefset.cpython-34.pyc
113639465   20 -rw-r--r--   1 areliabl areliabl    19060 Dec 28 19:16 
./random.cpython-34.pyc
areliabl at areliabledomain.com [~/py34/lib/python3.4/__pycache__]#