EOFError: marshal data too short -- causes?
Glenn Linderman
v+python at g.nevcal.com
Fri Jan 8 15:11:52 EST 2016
On 1/7/2016 7:44 PM, Dennis Lee Bieber wrote:
> On Thu, 7 Jan 2016 10:55:38 -0800, Glenn Linderman <v+python at g.nevcal.com>
> declaimed the following:
>
>> But all the touched files are .pyc files (and the directories
>> __pycache__ directories). None of the source files were modified. So
>> why would any .pyc files ever be updated if the source files are not?
>> Are there _any_ Python-specific reasons?
>>
> Two different versions of Python accessing the same modules? That might
> induce one to do a rebuild of the .pyc from the .py... Especially if the
> variant is something being run (directly or indirectly) from some scheduled
> task.
Thanks for the idea, but there is only one version of Python installed
in that directory structure (and all of my "shared host" portion of the
server).
> Some conflict with a backup process corrupting files?
This seems more possible, simply because I don't understand their backup
process. Still, if Python only reads shared, and there'd be no reason
for a backup process to do more than read shared, there shouldn't be a
conflict...
But it seems clear that there _is_ some conflict or some mysterious bug
that is triggering something.
The installation happened really fast, when I did it, many many files
seem to have the same timestamp. Maybe some of the sources are really
close in touch time to the .pyc? But still, it seems that would have
been resolved long ago... But I could go "touch" all the .pyc to give
them nice new timestamps?
Maybe I should mark all the current .pyc read-only even to myself? That
would prevent them from being rebuilt by Python, and maybe when whatever
goes wrong goes wrong, an error would return to the user, but maybe the
next access would work.... that'd be better than letting whatever goes
wrong modify/corrupt the .pyc, so that _every future_ access fails?
Maybe before launching Python I should do a "find ~/py34 --name *.pyc >
/dev/null" (or some log file) to cache the directory structure before
Python looks at it, and give the mysterious bug a chance to happen with
an irrelevant activity?
More information about the Python-list
mailing list