Overwriting an imported .mpy file causes crash

[deshipu]

When your program imports and uses a precompiled .mpy file, and you upload a new version of it, CircuitPython will often crash and stop responding.

[deshipu]

The crash is pretty bad — I have to reflash CircuitPython afterwards to make the board appear as USB drive again.

[dhalbert]

I tried a simple test case and could not reproduce this. Could you give a test case?

It may not be specific to .mpy files. What might be true is that there's a delayed write to the filesystem going on. If the board gets hard-reset (or unplugged/plugged back in) before the write is finished, then the filesystem can be corrupted.

Windows definitely has delayed writes, and on my Ubuntu 16.04 system, I am seeing them as well, though not as bad. My practice now is to run sync in the shell after editing or copying files.

[deshipu]

I think it just executes some random code then from the updated file, and depending on what code you hit, unpredictable things happen. And if they happen before the writing to the file is actually finished by your computer, you can get filesystem corruption.

[dhalbert]

Is this the scenario?

1. You have a main.py that does import some_mpy_module.
2. main.py is running (you're not in the REPL). Or you type ctrl-D in the REPL immediately after the copy.
3. You copy a new version of some_mpy_module.mpy to CIRCUITPY
4. Bad things happen.

So if the write is incomplete but auto-reload has been triggered, some_mpy_module.mpy will be messed up, and that could cause a problem.

[deshipu]

Ah, no, I wasn't explicit enough, my scenario is:

1. I have a main.py that does import some_mpy_module
2. main.py is running and is constantly calling functions it imported from some_mpy_module
3. New version of some_mpy_module.mpy file is copied from the computer
4. Bad things happen.

My theory is that main.py manages to call a function pointer, which no longer points to a correct place in the flash, before the reset happens.

[dhalbert]

I would not expect that scenario to be an issue, because the initial import will load the .mpy into RAM. After that point the running program is not going to reference the filesystem. A second import will be ignored because it's already loaded.

However, any file write through the USB drive will provoke a a auto-reload. CPy waits 500 msec for the write to complete and then simulates a ctrl-C. If the file is written incompletely, and a auto-reload happens, then a bad .mpy will be imported. For a .py file, one typically sees a syntax error instead when a bad or incomplete file is read.

If this is on Linux, could you try something like:
$ cp some_mpy_module.mpy /media/deshipu/CIRCUITPY; sync
to force an immediate flush. See if you can provoke the problem that way. Probably it will be much harder because the write will finish faster.

[deshipu]

The whole advantage of using .mpy files is that they are not loaded into RAM — the bytecode is ran directly from flash.

[dhalbert]

That is true of internal frozen modules. It is not true of regular .mpy files: they are not executed from the filesystem flash. All that you save is compiling. I was confused by this at first too; see https://forum.micropython.org/viewtopic.php?t=1962. Only frozen modules that are incorporated into the firmware at build time are executed from flash. Sad but true. I have a project that runs out of RAM even with .mpy's. I've had to add some of my (mostly unchanging) modules to the build. So I have custom firmware.uf2's.

[deshipu]

I think it depends on the platform a little. In any case, a crash does happen when I do the things I described. My theory about why it happens may be wrong, of course, but it still does happen.

[dhalbert]

Could you try the command line with sync above? That would help narrow it down to a delayed-write problem or not.

[deshipu]

Now I can't reproduce the problem, whether I use sync or not. I think I must just hit some unfortunate glitch, and attributed it to this problem, but in reality it's probably a delayed write as you suggest.

[tannewt]

Ok, sounds like this is too hard to repro to fix now. Please reopen if it happens again and we have a new lead.