Open littenduck opened 6 years ago
The crash happened on 2018-10-30 23:20, the file is saved as an empty file then.....???!
Search for "2018-10-30 23:20:20,953" in the log
The specific answer here is that the code in modes/python3.py:run_script needs to call save_and_encode rather than write_and_flush. And presumably the equivalent code in other modes as well; I'll check.
On a slightly wider note, I propose to add a fallback save somewhere which will do an emergency write-out using latin-1 (which will encode anything) if an exception is caught by the primary code. This will give us something of a recovery position if this kind of situation happens. We can also pop up a message indicating what's happened
We can pull back in this atomic file: PR https://github.com/mu-editor/mu/pull/208
It was removed because by default it saved the backup file in the same directory as the original and that caused problems on CircuitPython boards, but we can specify a different location for that mode.
I can't reproduce this bug in the current version of Mu on Win10. I have no problem in making the switch from write_and_flush to save_and_encode. But I can't seem to manage a failing test. I've tried the code from this issue and from #705 and it saves correctly.
Can anyone reproduce using the current HEAD?
I'll try to backtrack to the 1.0.1 release to see if I can reproduce from that, in which case I would assume we've inadvertently fixed the problem already.
Checked out the 1.0.1 tag and the test still succeeds.
I started using Mu 1.0.1 today and reproduced this. I copied and pasted Chinese characters from https://en.wikipedia.org/wiki/Chinese_language into a print statement: 国语/國語 Mu disappeared when I ran the script. When re-launching Mu, my hello.py script was empty. The crash did not reproduce on the second attempt.
The entirety of my script was:
print("Hello from Mu!")
print('国语/國語')
The relevant portion of the log appears to be:
2019-01-03 11:09:05,915 - root:95(excepthook) ERROR: Unrecoverable error
Traceback (most recent call last):
File "C:\Users\chumbers\AppData\Local\Mu\pkgs\mu\modes\python3.py", line 162, in run_toggle
self.run_script()
File "C:\Users\chumbers\AppData\Local\Mu\pkgs\mu\modes\python3.py", line 189, in run_script
write_and_flush(f, tab.text())
File "C:\Users\chumbers\AppData\Local\Mu\pkgs\mu\logic.py", line 152, in write_and_flush
fileobj.write(content)
File "encodings\cp1252.py", line 19, in encode
UnicodeEncodeError: 'charmap' codec can't encode characters in position 32-33: character maps to <undefined>
2019-01-03 11:09:15,108 - root:112(run) INFO:
I have python 3.7 (32-bit) installed. The entire Log is attached. log.txt
The fix hasn't been released yet, could you try the latest installed from this list and see if it works in that version? http://mu-builds.s3-website.eu-west-2.amazonaws.com/?prefix=windows/
It works, but I don't think it is a valid test. It appears that the crash is intermittent, or that I don't know the right steps to guarantee the crash. I couldn't reproduce the crash with 1.0.1 on another Windows 10 machine.
I did the following to test with Master:
I then uninstalled the build from Master and re-installed 1.0.1. No crash.
The same has happened to me on my mac. Unfortunately, because it wiped the code I can't share it. However it might have something to do with Running code without saving it first. I am on version 1.0.0
Hi folks,
This issue will be fixed in the upcoming 1.0.2 release.
Hi folks,
This issue will be fixed in the upcoming 1.0.2 release.
@ntoll: did you fix this already? We already have a 1.0.2 release, and I guess you included a fix, or what is the status here? If you remember... at least we haven't heard any new reports about it for two years.
Hi @dybber
Hmm... I've just taken a look at the code. The TL;DR is that I am an idiot and @carlosperate is not. :-)
Here's the more in-depth situation:
AtomicFile
class (the first one being a temp backup), then the CircuitPython boards would re-start before the second "real" write to the device.atomic
which defaults to True
when we save a file. In CircuitPython mode, we can switch the flag to False
and "normal" Python writes to the device happen (surrounded by a try
/except
just in case).Sound like a plan..?
It's been a long time since I looked at the atomic write, but if I remember correctly we could also change the temp file to be in a different directory (like the OS temp dir), so that the last step (the file move performed kind of atomically) can still be done the same, just not from within the CIRCUITPYTHON drive. For other modes it can still be useful to have the temp file next to the original, as after a Mu crash the user can still easily retrieve it.
Exactly. :+1:
I believe this problem is guarded against given the current state of the code that handles file saves (see save_tab_to_file
in logic.py
). Would be good if someone could take a quick look and confirm. If so we can close this issue.
Perhaps I'm wrongheaded, but from a circuitpython workflow point of view having a configurable place to put copies of stuff written to flash would be delightful. I have a class with multiple groups working on similar bots, and sharing/versioning code that lives only on the flash drives is a pain. If a copy of the code lived somewhere on the host machine (without the back-and-forth of repeated "Save As") some of the interaction among students would be much easier. So I'm cheering on whoever is working on this infrastructure.