Bug 33752 - AutoSave during completion causes crashes
Summary: AutoSave during completion causes crashes
Status: RESOLVED ANSWERED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Text Editor ()
Version: unspecified
Hardware: PC Linux
: Normal normal
Target Milestone: master
Assignee: Mike Krüger
URL:
Depends on:
Blocks:
 
Reported: 2015-09-07 17:58 UTC by ommymyca-6408
Modified: 2015-12-07 08:38 UTC (History)
1 user (show)

Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Log of event (4.27 KB, text/x-log)
2015-09-11 08:17 UTC, ommymyca-6408
Details


Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community or GitHub with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED ANSWERED

Description ommymyca-6408 2015-09-07 17:58:11 UTC
Description of Problem: AutoSave during completion causes crashes.


Steps to reproduce the problem:
1. Keep coding and popping up completion lists.
2. At some point, it may or may not crash -- yes, I know, hard to reproduce.


Actual Results:

Randomly, version 5.9.5 of MonoDevelop will crash on, at least on my configuration. It is very hard to reproduce specifically but, after some experimenting I did find a way to avoid it -- saving manually, often. This in turn led me to conclude that it somehow is related to autosaving. Additionally, whenever it does crash, the autosave it does provide me with after opening it again is extremely close to what I was doing at the time of the crash, suggesting the autosave happened only moments prior to the crash. As a workaround, I tried looking for an option to simply disable the autosave feature but for some reason I was unable to find it while I remain quite sure I did see it in there somewhere in a previous version. Was it removed or am I simply overlooking it?

Expected Results:

I expect autosaving not to crash at all.

How often does this happen? 

Irregularly.

Additional Information:

AMD A6-3650; Linux kernel version 4.2; Xubuntu 15.04; ext4 filesystem; cat /proc/meminfo: MemTotal: 3508480 kB
Comment 1 Mike Krüger 2015-09-08 07:48:18 UTC
I can't imagine any way auto saving can cause crashes. It's unrelated to the editor content - however only in the 6.0 version I can guarantee it since the 5.x editor isn't 100% thread safe.

Can you provide me a an exception text or crash dump ?
Comment 2 ommymyca-6408 2015-09-08 18:07:56 UTC
If you could tell me where I can find those; since MonoDevelop truly CTDs (crashes to desktop). No error message, no exception handler popping up. It simply dies. Completely.

I'm assuming they're in .cache/MonoDevelop/Logs? If so, I'll see if I can generate the event (BleachBit cleaned the intermediate logs, so I have nothing to share at the moment, since I've been avoiding the phenomenon completely by excessive manually saving; either an actual hard-save or just compiling).
Comment 3 Mike Krüger 2015-09-09 01:13:11 UTC
y it's either in these logs or on the console on linux.
You'll need to start monodevelop from a terminal in that case.
Comment 4 ommymyca-6408 2015-09-11 08:17:17 UTC
Created attachment 12871 [details]
Log of event

Attached log of event.
Comment 5 ommymyca-6408 2015-09-11 08:20:07 UTC
Note: The "Error while creating text editor extension :__nid_15(MonoDevelop.CSharp.UnitTestTextEditorExtension)" I have seen pop up in the logs on a semi-regular basis without it crashing, so that seems unrelated. In fact, the log tells me personally very little. The latest normal entry is the "INFO [2015-09-11 14:13:57Z]: Add-in loaded: MonoDevelop.Debugger.Soft", which I would say seems normal. It does not read ERROR or anything.

And then, the stacktrace.

Note also that this was when started from a terminal and there was simply no terminal/stdout message whatsoever; again, MonoDevelop simply completely died. Finally, note that this happened when creating a new Gtk# 2.0 project (just to test) and seemed to happen during the initial autosave.
Comment 6 ommymyca-6408 2015-09-12 18:09:25 UTC
5.9.5 in general just seems unstable; I've also been getting Fatal Errors upon closing MonoDevelop. With the request to send a bug report, which I do (obviously). But still, this type of instability I have not seen before in MonoDevelop.

Maybe it somehow is linked to the Linux kernel and its recent (extremely) low level changes? As in, some scheduler timings going awry for MonoDevelop?
Comment 7 Mike Krüger 2015-09-13 01:14:55 UTC
Maybe - native crashes are always a very bad sign :(
Comment 8 ommymyca-6408 2015-09-13 11:53:15 UTC
Well, given your own remark about 6.0 being 100% thread safe, I am going to go out on a limb here and assume the problem will dissipate on its own in 6.0. In the meantime, I suppose I could give kernel 3.19.x a try to see if the problem persists. Sadly, it is still quite hard to force the phenomenon. Consequently, I cannot guarantee I'd have results forthwith.
Comment 9 ommymyca-6408 2015-09-13 12:25:03 UTC
Running 3.19.8ckt6 at the moment and while the machine a lot of stuff to do (Twitch stream, Youtube video @ 60 FPS, disk activity, Steam (in Wine), Clicker Heroes (in Wine)) I went ahead and repeatedly opened MonoDevelop, created a new Gtk# 2.0 project and closed MonoDevelop again. So far, after a dozen tries or so, it still has not shown evidence of crashing as before.

Whereas it did crash on the very first attempt of a Gtk# 2.0 project (the choice is incidental, it's just as an example and is one of the more complex standard project templates in MonoDevelop) in kernel version 4.2. Further proof of my assumption that it indeed is somehow linked to the low level scheduler and ASM>C changes in the kernel. Obviously, this still is an issue worth investigating, since this design paradigm of bringing the Linux kernel into a more modern era of coding seems to be here to stay.

All I can do at this time is wait for MonoDevelop 6.0 and try to crash it on Linux kernel 4.x. ;)
Comment 10 ommymyca-6408 2015-09-14 19:39:58 UTC
Back on 4.2 and it randomly occured again:

	monodevelop() [0x4b23dc]
	monodevelop() [0x508a0e]
	monodevelop() [0x428fad]
	/lib/x86_64-linux-gnu/libpthread.so.0(+0x10d10) [0x7f85bd60dd10]
	monodevelop() [0x5a2459]
	monodevelop() [0x559cf2]
	[0x409902d2]

Once again libpthread. This time the event actually occured reasonably short (half a second to a full second) after hitting save all. So, even manually saving isn't 100% foolproof.
Comment 11 Mike Krüger 2015-09-27 04:48:23 UTC
if you're compiling monodevelop from source it's possible to get 6.0 today.

It's the roslyn branch:

https://github.com/mono/monodevelop/tree/roslyn

btw. I made a blog post about it a while ago:

http://mikemdblog.blogspot.de/2013/09/how-to-set-up-monodevelop-on-linux.html
Comment 12 ommymyca-6408 2015-09-29 19:48:52 UTC
Well, as long as it's just MonoDevelop that is crashing, I'm fine. So far, none of my own applications (password manager, Clicker Heroes bot, experiments) have crashed, the runtime (Mono) itself seems fine. So, whereas coding them randomly runs into minor issues, actually using them does not. Thanks for the suggestion though and for the very informative blog post.
Comment 13 Mike Krüger 2015-09-30 01:03:53 UTC
Finding native crashes is not easy. Usually they're caused by calls to native libraries like gtk. 
Maybe that one above is caused by a gtk call from a background thread or something like that.

In general the goal of .NET is that native crashes do not happen - but if you're using many C wrappers - like we do - it happens :/. We need much deeper .NET only solutions for everything :)