Bug 11445 - Xamarin Studio crashes on startup
Summary: Xamarin Studio crashes on startup
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Docking ()
Version: unspecified
Hardware: Macintosh Mac OS
: Normal normal
Target Milestone: ---
Assignee: Marius Ungureanu
Depends on:
Reported: 2013-03-27 11:12 UTC by Tony T
Modified: 2017-09-26 12:10 UTC (History)
7 users (show)

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

Editing layout from ~/Library/Preferences/XamarinStudio-4.0 (13.24 KB, text/xml)
2013-03-27 11:12 UTC, Tony T
Crash log (76.11 KB, application/octet-stream)
2013-03-27 16:54 UTC, Tony T
Tester playing with GdkRegion unions (2.45 KB, text/x-csrc)
2013-04-25 11:29 UTC, Aleksander Morgado
Updated tester, using multiple threads to break the union (4.51 KB, text/x-csrc)
2013-04-26 05:19 UTC, Aleksander Morgado

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:

Description Tony T 2013-03-27 11:12:13 UTC
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.
Comment 1 Mikayla Hutchinson [MSFT] 2013-03-27 13:11:33 UTC
Can you please attach the crash trace too?
Comment 2 Tony T 2013-03-27 16:54:52 UTC
Created attachment 3710 [details]
Crash log
Comment 3 Mikayla Hutchinson [MSFT] 2013-03-27 19:54:53 UTC
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)
Comment 4 Kristian Rietveld (inactive) 2013-03-28 03:45:49 UTC
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.
Comment 5 Aleksander Morgado 2013-04-25 11:29:08 UTC
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...
Comment 6 Aleksander Morgado 2013-04-26 05:19:28 UTC
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)

Comment 7 Kristian Rietveld (inactive) 2013-04-26 05:26:33 UTC
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);
Comment 8 Kristian Rietveld (inactive) 2013-04-26 06:05:19 UTC
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.
Comment 9 Marius Ungureanu 2017-09-26 12:10:28 UTC
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.