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:

areli...@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)?


areli...@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
areli...@areliabledomain.com [~/py34/lib/python3.4/__pycache__]#

--
https://mail.python.org/mailman/listinfo/python-list

Reply via email to