Closed bclmary closed 4 years ago
I have observed this also. Not often, but 2 or 3 times total in several months of regular use.
Editing a document in dual-pane view; just typing along, and bam! Formiko window ceased to exist, leaving a gap in my taskbar. (In my case the window didn't freeze, but vanished instantly and without warning.)
ps ax | grep formiko
shows there is no formiko process.
Sure enough, the file still exists, but size 0 bytes, and opening it confirms that it's completely blank.
Note: This file has existed for weeks, and has been saved dozens of times (maybe hundreds), and Formiko's crash did not just lose unsaved work, or even just work from the current session; it nuked the entire contents of the file on disk.
Fortunately, I was working on a file that's managed by a cloud sync client, so I can revert to a previous version. Otherwise my best-case scenario would be to revert from last night's backup. I would rate this as severity: critical.
Please could you try to run formiko from terninal, if is there some other informations? I'm working with formiko daily, but this bug is not easy to replicate. So any other information like last operation before shooting down, like coping to/from buffer, scrolling, file size, etc.
I'd love to, but at the risk of asking a n00b question: how do I get debugging output from formiko?
$ formiko
→ opens a formiko window, but seems to immediately separate itself from the terminal (ie I'm immediately returned to the $
prompt), and opening/editing/saving/closing a file in the formiko window produces no output in the terminal.formiko >> .local/formiko-logs/"$(date -Iminutes)" 2>&1
→ also opens a formiko window, and creates the log file, but opening/editing/saving/closing a file in the formiko window doesn't cause anything to be written to the log file.formiko --help
does not seem to say anything along the lines of 'verbose', 'debug', or 'logging'.In the meantime, would it make sense to implement a "working copy" mechanism like many text editors use to prevent data-loss? Something like the following:
filename.md
to filename.md~
filename.md~
, and after every successful 'save', we (ask the OS to) copy filename.md~
over the original filename.md
filename.md~
That way, whatever the bug is, it should only nuke the working copy when it strikes (losing the user's work since last autosave) instead of losing the entire file.
Formiko is "standard" GTK Application, so it is run as Application server and client. If any Formiko is alive, next running formiko starts a client of first "server" instance. If there is error in client. That is why is running at foreground and you get prompt in your console. You can get some gtk-debug. Something about debugging is here: https://developer.gnome.org/gtk3/stable/gtk-running.html
And, i will do as you write in some near next release. Just save to another file, and when saving, copy the working version to original.
But, that not solve the problem, only help fix some fatal aftermath of that. So if you told me any other information about that, it could help me much. Any details could be important like:
Thank's a lot, for all, for using, for bug report and for any other information which could help me fix his fatal error.
Okay, we're getting closer...
Starting in a fresh X session, launching Formiko from a terminal window does keep the process foregrounded in that window and produce some output. The default level is not very talkative, and only shows a recommonmark warning about "skipped container node". Opening a file, saving changes, and quitting Formiko produce no output.
After a quick look at the GTK debugging stuff at that link, I tried launching Formiko with --gtk-debug all
. Well, that sure produced some output! Every scroll, every menu item I hovered over on my way to choosing one—my console window was drowned in output. It also turned the Formiko window into an unusable mess of different highlight colours overlaid on all the UI elements, and the edit pane turned solid red whenever it was not in focus... So that's no good either.
How about you tell me which --gtk-debug
options to turn on in order to capture the information that is helpful for you, while still allowing the application to be usable? I am not knowledgeable in GTK, and most of the terminology in that list means nothing to me. Once I know what to capture, I'll set up a wrapper script to dump it all in a log file.
I can answer some of your questions already:
is the file on USB or on Disk?
Internal SSD
is the system hibernete throw the work with formiko?
Nope, I have hibernate and suspend disabled.
is the original file bigger than XYZ kB?
19.1 KiB or less.
is the application uptime longer than N hours?
I can tell you it has happened at less than 8 hours uptime. I'll be more specific if/when it happens again.
when formiko crash, crash any other application or service?
No. I did notice that it left a gap in my xfce4 taskbar, which is not usual. (Normally when a program closes, the other items rearrange so there is no gap.) Other than that minor quirk, everything else on my system continued to behave as expected.
what tell you when it happens /var/log/messages <- there could be some other informations?
In the future, I should be able to capture this, yes.
when it happens, do you write some special format character for example?
I don't have a definite answer to this yet, but I think last time it happened I was typing regular text.
do you have enabled auto save?
Yes.
Thanks a lot! I thing, that the default logging from formiko (without any other gtk-debug option) could be fine. This error is probably somewhere in python code, so if some crash with application fall, it will be print to stderr so to console.
At the moment, i have opened window a few days, but without any special working with. But with hibernating. So may be, i catch the problem. And yes, in next days, i add the save / working file logic.
You're welcome! And thanks for your work on formiko!
I have written a wrapper script to launch the program and capture launch time, stdout & stderr, exit time, and the tail of /var/log/messages
at the moment the program exits. So, if/when I encounter that crash bug again, hopefully I'll have some useful info for you.
In case it's helpful for @ondratu or anyone who wants to help with the debugging, here's my logging-wrapper bash script.
At last, my logging wrapper script has paid off! /var/log/messages
shows a segfault.
Here's everything I captured:
Edited to add: I had two files open at the time, and only the one I was typing in got nuked. Same symptoms as before; the file still exists but is completely empty and ls -l
shows its size as zero bytes.
Error, which you send me, and which i see more times is fixed now. Please try the last version from git.
I was enjoying formiko for the 5th day of trial, working on a .rst file. Then formiko freezed. Ok, no panic, I just waited until some error message may appear... ...But formiko just died, taking my work with him (I'm quite sure I heard a satanic laugh). My file was still here, but empty. 0 Ko. Even with recovery app, such as testdisk, no help. This is bad. [Ubuntu 18.04, gnome version, repos version of formiko]