EOFError: marshal data too short -- causes?

[Glenn Linderman]

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?