IDE crashed, source code file corrupted

Status
Not open for further replies.
D

DrM

Well-known member
While working in the teensy/arduino IDE 1.8.10, in fedora 31, the system first complained that it could not find the teensy device, and then locked the host OS.

After rebooting, the ino file is corrupted, it ends somewhere in the middle. and everything after that is lost.

Does the IDE maintain a backup? Where?


BTW, guys, this is not a sign of good workmanship on the part of the IDE. But then maybe that's just POV, I'm pretty p/o'd.
 
Teensy files are plugins for the Arduino IDE. File saving is handled by the Arduino IDE and yes the Arduino IDE is very basic as IDE's go.

As far as I know it does not keep any backups, but it should have saved your file when you compiled the code.

The issue you describe sounds like you might have run out of disk space?


Linux generally is pretty good about making sure your files do not get corrupt if you are using a journaling filesystem like EXT4.
 
Under windows the Arduino IDE generates a temp file in C:\Users\YOUR-ACCOUNT\AppData\Local\Temp\arduino_buildxxxxxxxx which it uses for compiling.

I thought this might have allowed you to get the file back but under Linux the IDE uses the /tmp filesystem which is normally a RAM filesystem or deleted during the boot process.
 
Of course it did save the file when it last compiled, and then when it crashed, it overwrote that file up to line #whatever, and that is what I had after the machine rebooted.

It did not run out of disk space and it is ext4 with journaling. And indeed yes,Linux usually does do a fantastic job of saving your files across a crash.

The Arduino IDE stands out both in being able to crash linux and in managing to corrupt a file in the process.

Since you didnt mention it, I assume there is no switch or parameter to save the tmp file somewhere other than a ram resident file system?

Fortunately I had an earlier version of the ino, from a few days back, I used that to manually reconstruct the work since then.
 
Last edited:
It's the IDE, if a PC is unstable and crashes, under rare circumnstances during an upload or save when the crash occurs, you can end up with a blank sketch.
 
The PC in this case is not unstable, it has never crashed under any other circumstances. It was very clear at the time that it was the ide and its interaction with the teensy that did it.

The central point here is that there should be another file, in something other than a ram resident tree, that holds the previous state before the save starts overwriting the current file. In fact there should be two, one an automatic backup when the ide opens the file, and second, updated periodically and at every save or compile. Seriously, it has to be fixed.
 
DrM said:
The PC in this case is not unstable, it has never crashed under any other circumstances. It was very clear at the time that it was the ide and its interaction with the teensy that did it.
Click to expand...

I suspect the USB (serial?) driver is buggy - nothing outside the kernel or drivers should be able to crash the OS. Have you
used USB serial other than with Arduino/Teensy development?

I've noticed the same sort of problem on an old version of MacOS - in particular removing the USB plug while connected to
USB serial tends to provoke 20s hangs, and eventually a kernel panic. The fact this is when talking to Arduino is irrelevant,
the USB driver is at fault (can't remember if its MacOS or third-party). At least I can workaround this by being careful about
unplugging.
 
DrM said:
While working in the teensy/arduino IDE 1.8.10, in fedora 31, the system first complained that it could not find the teensy device, and then locked the host OS.
Click to expand...
TD does not support Arduino IDE 1.8.10, which was recognized as buggy and immediately replaced with 1.8.11.
 
Yes, I thought it might be the usb flooding the serial monitor tool launched by the IDE, and then perhaps crashing the desktop. But it did disconnect spontaneously a few times along the way.

But again, I think this is a side issue. Crashes should be expected when you work with hardware.

That the IDE is not protecting the work files, and even worse, can corrupt the source code file in a non-recoverable way, is very very serious. It really has to be fixed right away.
 
In years here on Windows with IDE it has crashed when USB gets flooded or confused with abusive USB teensy output or Teensy evolution too fast to handle - but never lost any source files on build.

As noted 1.8.10 had issues and quickly replaced - then again on 1.8.12 as changes to JAVA usage had issues. So IDE 1.8.13 is the current version for some known reasons.

Using here Win 7 to Win 10 and Paul@PJRC works with Ubuntu and Mac. There may be some unfound issues with the OS in use.

Common use case here is External Editor - or no IDE at all with Windows command line execution from editor. There are ways around using the IDE editor. Losing files would be disturbing, if it were common across the user base it would be addressed.

If there is a preferred external editor there - would suggest update to IDE 1.8.13 and try setting preference to external editor so IDE will only read source files for building.
 
That sounds really helpful, both parts; update to current version and use an external editor. I did not realize 1.8.10 was out of date, it seems like not so long ago that I installed it.

So, is 1.8.13 going to be stable for a while?

My preferred editor is emacs and all of our machines are linux.
 
Paul monitors the chatter on the Arduino github and usually gets a feel for a pending release. 1.8.13 seems stable and Paul certainly hoping it stays active for some months as he has to drop everything to update TeensyInstaller. Releases like recently with 1.8.10 and 1.8.12 can get a spontaneous update when general problems develop.

Sounds like external editor should work there then. Just check the box and IDE can open and build - but blocks edits and just reads current file for build expecting external edits.
 
Status
Not open for further replies.
Back
Top