Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
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
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.
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.
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?
I expect autosaving not to crash at all.
How often does this happen?
AMD A6-3650; Linux kernel version 4.2; Xubuntu 15.04; ext4 filesystem; cat /proc/meminfo: MemTotal: 3508480 kB
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 ?
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).
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.
Created attachment 12871 [details]
Log of event
Attached log of event.
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.
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?
Maybe - native crashes are always a very bad sign :(
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.
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. ;)
Back on 4.2 and it randomly occured again:
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.
if you're compiling monodevelop from source it's possible to get 6.0 today.
It's the roslyn branch:
btw. I made a blog post about it a while ago:
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.
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 :)