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.
The first time MD has an unhandled exception, the crash reporter shows a dialog saying that a "crash" has occurred and asking the user to enable submission.
This has several problems
a) It's not a crash, the text is incorrect
b) The actual exception is not shown, so users cannot file it manually, and do not see the kind of information that will be submitted
c) There is no option to submit just this one error
On subsequent unhandled exceptions, MD shows the trace, with the message "An unhandled exception has occurred. Details of this crash have been submitted for analysis. This has several issues:
a) The vertical scrollbar is not visible, but the body of the detail text is taller than the text widget - it can be scrolled by drag-selecting.
b) The text is incorrect, it's not a crash
c) The text is too technical, it shouldn't refer to unhandled exceptions, it should say something like:
"MonoDevelop has encountered an unexpected error and may not have completed the operation successfully. Details of this error have submitted for analysis."
d) The exception detail should not be shown by default, it should be shown in a collapsed expandable box.
In addition, the unhandled exceptions no longer appear to be written to the MonoDevelop log files.
Also, the new rotated log files are confusing because there's a lot of information out there that says to check MonoDevelop.log, which will now always be stale. IMO MD should either link MonoDevelop.log to the latest log file, or delete it.
The first time:
a) Good point. It is not always a crash and this text can be cleaned up to properly explain this.
b) This is by design. The opt-in/out dialog was not supposed to display any sort of crash info.
c) Again, by design. If the user opts out then every future crash dialog will say something along the lines of "This has not been submitted as crash reporting has been disabled". This is their on-going reminder to opt in.
On subsequent exceptions:
a) The property set to enable vertical scrolling was accidentally removed. It's already back in
b) There needs to be two sets of text, one for an actual crash which terminates MD and one for when it doesn't. I'll add latter.
c) Good point
d) I wanted to ping you about this as I had trouble finding the correct MonoMac control to implement this behaviour.
This is something I noticed too but haven't changed as of yet. I was thinking of writing the log files to MonoDevelop.log and then when MD starts up, renaming the existing MonoDevelop.log to the form:
This way the latest is always called "MonoDevelop.log" (an expectation we should keep if at all possible) and the user will trivially be able to relate an older log file to an exact session. The session uuid will be written inside the log instead of being part of the filename.
b) Then how are users supposed to know what information we are submitting, and if they opt out how can they manually report that first error?
c) That's a shame, I'm sure we'd get more reports if we had an option to report individual errors.
d2) Yeah, this kind of thing is complicated, IIRC there's a specific kind of button you have to use then manually resize the window and add the new control in but you you can get the slidey-widow thing going.
The problem with renaming on next session is that multiple instances of MD will still collide. What the matter with a link?
Also, cmd-c etc don't work in the details textview.
Command-c/a/x now work. I never tested that behaviour and didn't realise it didn't work by default. I've implemented the UI for always/just this time/never as part of a combined "opt-in and display information" dialog.
I sorted out the MonoDevelop.log file issue. This is a symlink to the latest file on linux/macos. On windows we rename MonoDevelop.log to MonoDevelop.[TIME_STAMP].log on startup and also handle the case where there are multiple concurrent monodevelop instances.
I think all the issues have been resolved so marking this as resolved for now, but do reopen if I missed something!