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.
Created attachment 3703 [details]
Editing layout from ~/Library/Preferences/XamarinStudio-4.0
Every time I start Xamarin Studio I get a dialog that says "Restore Windows The Application "Xamarin Studio" unexpectedly quit while trying to restore its windows. Do you want to try to restore its windows again?". Either possible response (Restore or Don't Restore) results in a crash.
I have the latest stable version of XS, X.iOS and X.Android.
I deleted ~/Library/Preferences/XamarinStudio-4.0 and was able to run XS. Attached is the preferences file EditingLayout.xml which I think is the problem.
A related fact is that I run XS on a MacBook with a huge external monitor (3360x1050) and my pads are all docked to the right in a single dock that is the size of, or larger than, my built-in display. I do sometimes disconnect the huge monitor and work from home on just the built-in display. I will assume that this is part of the problem and make my pad dock smaller than the built-in display. If the crash still happens then I will update this bug.
Can you please attach the crash trace too?
Created attachment 3710 [details]
Hm, it's the miRegionOp crash again. Sounds like the docking system is laying out bad sizes, but that shouldn't hard crash GTK+
8 libsystem_c.dylib 0x033ecbdd abort + 167
9 libglib-2.0.0.dylib 0x0c3f93bb g_assertion_message + 555
10 libglib-2.0.0.dylib 0x0c3f948c g_assertion_message_expr + 124
11 libgdk-quartz-2.0.0.dylib 0x0cba4240 miUnionNonO + 208
12 libgdk-quartz-2.0.0.dylib 0x0cba4010 miRegionOp + 976
13 libgdk-quartz-2.0.0.dylib 0x0cba4ef3 gdk_region_union + 419
14 libgdk-quartz-2.0.0.dylib 0x0cba2e4f gdk_region_union_with_rect + 239
15 libgtk-quartz-2.0.0.dylib 0x0c91e611 gtk_widget_size_allocate + 721
16 libgtk-quartz-2.0.0.dylib 0x0c65eed4 gtk_box_size_allocate + 1284
17 libgobject-2.0.0.dylib 0x0d3ec7d9 g_cclosure_marshal_VOID__BOXED + 233
18 libgobject-2.0.0.dylib 0x0d3e99ce g_type_class_meta_marshal + 142
19 libgobject-2.0.0.dylib 0x0d3e95bf g_closure_invoke + 511
20 libgobject-2.0.0.dylib 0x0d409620 signal_emit_unlocked_R + 1616
21 libgobject-2.0.0.dylib 0x0d4088e6 g_signal_emit_valist + 2662
22 libgobject-2.0.0.dylib 0x0d408db1 g_signal_emit + 65
23 libgtk-quartz-2.0.0.dylib 0x0c91e5ae gtk_widget_size_allocate + 622
24 libgtk-quartz-2.0.0.dylib 0x0c6d01d2 gtk_event_box_size_allocate + 418
25 libgtksharpglue-2.so 0x1538f056 gtksharp_widget_base_size_allocate + 86 (generated.c:5243)
If it's a real miRegion issue, it should crash on Linux as well. Perhaps a good idea that we put together some extensive unit testing for GdkRegion including a bunch of random tests to try to trigger the bug.
I can try to pull the exact crash condition of the above trace from the assembly so that we can explicitly test all possible corner cases for this condition.
Created attachment 3874 [details]
Tester playing with GdkRegion unions
I've tried to setup a tester program to try to reproduce the issue, attached. The issue is definitely not Mac-specific; as the code handling the region unions is platform-agnostic. Now, I cannot reproduce the issue, and the tester performs quite some many checks (with overlapping, with partial overlapping, without overlapping...). I don't think this is an unhandled cornercase.
Also checked the logic behind the region unions. The specific miUnionNonO() assertions given seem to be exactly the ones needed; the previous logic takes care of handling the region intersections when the regions overlap, and for the regions which don't overlap, miUnionNonO() gets called.
I've also googled for the miUnionNonO assertions, and there are lots of reports everywhere. All the reports I've seen got the issue fixed by properly locking/unlocking GDK threads, which kind of makes sense, as the miRegionOp() operation uses the source1 region also as output, so multiple operations on the regions at the same time will make them behave badly. And for what I can see, this is the only logical reason for this issue to happen...
Created attachment 3878 [details]
Updated tester, using multiple threads to break the union
This updated tester uses a thread pool to simulate the clash when using a single GdkRegion from different threads and without protection.
I can easily reproduce now the assertions:
Gdk:ERROR:gdkregion-generic.c:1137:miUnionNonO: assertion failed: (y1 < y2)
Gdk:ERROR:gdkregion-generic.c:1143:miUnionNonO: assertion failed: (r->x1 < r->x2)
I confirm that the multi-threaded tester also causes crashes on OS X (both in 64-bit and 32-bit GDK binaries).
For completeness, the assert that is hit in the trace in comment 3 is:
g_assert(r->x1 < r->x2);
The exact assert does not really matter, as the region is only briefly used from a GTK+ size allocate routine.
As Aleksander has mentioned, there are numerous reports on the web of this assertion being triggered when widgets are being updated from outside of the main thread. We therefore suspect that this is a MonoDevelop bug.
There is now logging added for this issue in Gtk# that asserts that Gtk# calls are done on the UI thread. The piece of code in gdk is not thread-safe, so this is the only way to fix it.
Various usages of Gtk/Gdk in a background thread were fixed over time. Marking the bug as fixed.