Bug 6630 - Crash in GdkQuartzWindow when showing code completion dialog
Summary: Crash in GdkQuartzWindow when showing code completion dialog
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: Text Editor ()
Version: unspecified
Hardware: PC Mac OS
: Normal normal
Target Milestone: ---
Assignee: Mike Krüger
URL:
: 7205 8011 8647 8751 ()
Depends on:
Blocks:
 
Reported: 2012-08-21 13:23 UTC by Bojan Rajkovic [MSFT]
Modified: 2013-04-03 18:16 UTC (History)
13 users (show)

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


Attachments
C code to display monitor configuration (589 bytes, application/octet-stream)
2013-01-20 15:00 UTC, Kristian Rietveld (inactive)
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 FIXED

Description Bojan Rajkovic [MSFT] 2012-08-21 13:23:34 UTC
Mono version: 2.10-series build from Wrench, or master build from Wrench.
MonoDevelop version: Any

A consistently reproducible crash occurs when showing the code completion window on any Mono version newer than the released Mono 2.10.9. The crash happens every time inside GdkQuartzWindow, and is sometimes preceded by the following message:

8/21/12 12:37:56.070 PM MonoDevelop[38605]: CGSNewWindowWithOpaqueShape: Malformed reigon

The crash itself always takes form with the following native stack trace:

Application Specific Information:
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1007) creating CGSWindow'

Application Specific Backtrace 1:
0   CoreFoundation                      0x971c47ab __raiseError + 219
1   libobjc.A.dylib                     0x9728d602 objc_exception_throw + 230
2   CoreFoundation                      0x9712423b +[NSException raise:format:] + 139
3   AppKit                              0x9590545c _NXCreateWindowWithStyleMask + 302
4   AppKit                              0x9599bf35 _NSCreateWindow + 57
5   AppKit                              0x95819f73 -[NSWindow _commonAwake] + 2066
6   AppKit                              0x957d6c77 -[NSWindow _commonInitFrame:styleMask:backing:defer:] + 1652
7   AppKit                              0x957d5d3f -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1063
8   AppKit                              0x957d5904 -[NSWindow initWithContentRect:styleMask:backing:defer:] + 70
9   AppKit                              0x95e4e24c -[NSWindow initWithContentRect:styleMask:backing:defer:screen:] + 79
10  libgdk-quartz-2.0.0.dylib           0x02dda060 -[GdkQuartzWindow initWithContentRect:styleMask:backing:defer:screen:] + 144
11  libgdk-quartz-2.0.0.dylib           0x02df391f _gdk_window_impl_new + 1359
12  libgdk-quartz-2.0.0.dylib           0x02dc3e69 gdk_window_new + 1369
13  libgtk-quartz-2.0.0.dylib           0x02b4f092 gtk_window_realize + 962
14  libgobject-2.0.0.dylib              0x027ed9df g_cclosure_marshal_VOID__VOID + 223
15  libgobject-2.0.0.dylib              0x027eb9ce g_type_class_meta_marshal + 142
16  libgobject-2.0.0.dylib              0x027eb5bf g_closure_invoke + 511
17  libgobject-2.0.0.dylib              0x0280b620 signal_emit_unlocked_R + 1616
18  libgobject-2.0.0.dylib              0x0280a8e6 g_signal_emit_valist + 2662
19  libgobject-2.0.0.dylib              0x0280adb1 g_signal_emit + 65
20  libgtk-quartz-2.0.0.dylib           0x02b32dcf gtk_widget_realize + 495
21  libgtk-quartz-2.0.0.dylib           0x02b32da5 gtk_widget_realize + 453
22  libgtk-quartz-2.0.0.dylib           0x0299201b gtk_menu_popup + 1147
23  ???                                 0x06d8a934 0x0 + 114862388
24  ???                                 0x06d8a7d8 0x0 + 114862040
25  ???                                 0x06d8a728 0x0 + 114861864
26  ???                                 0x06d8a584 0x0 + 114861444
27  ???                                 0x06d8a504 0x0 + 114861316
28  ???                                 0x06d89880 0x0 + 114858112
29  ???                                 0x06d89834 0x0 + 114858036
30  ???                                 0x06d8975c 0x0 + 114857820
31  ???                                 0x10ee9124 0x0 + 284070180
32  ???                                 0x10c247a2 0x0 + 281167778
33  ???                                 0x069859b0 0x0 + 110647728
34  libgtk-quartz-2.0.0.dylib           0x0298923e _gtk_marshal_BOOLEAN__BOXED + 286
35  libgobject-2.0.0.dylib              0x027eb9ce g_type_class_meta_marshal + 142
36  libgobject-2.0.0.dylib              0x027eb5bf g_closure_invoke + 511
37  libgobject-2.0.0.dylib              0x0280be94 signal_emit_unlocked_R + 3780
38  libgobject-2.0.0.dylib              0x0280a98c g_signal_emit_valist + 2828
39  libgobject-2.0.0.dylib              0x0280adb1 g_signal_emit + 65
40  libgtk-quartz-2.0.0.dylib           0x02b35efd gtk_widget_event_internal + 749
41  libgtk-quartz-2.0.0.dylib           0x02b3596f gtk_widget_event + 319
42  libgtk-quartz-2.0.0.dylib           0x0298702e gtk_propagate_event + 654
43  libgtk-quartz-2.0.0.dylib           0x02985416 gtk_main_do_event + 694
44  libgdk-quartz-2.0.0.dylib           0x02de6319 gdk_event_dispatch + 153
45  libglib-2.0.0.dylib                 0x026b1d61 g_main_dispatch + 513
46  libglib-2.0.0.dylib                 0x026b365b g_main_context_dispatch + 155
47  libglib-2.0.0.dylib                 0x026b3c8a g_main_context_iterate + 1466
48  libglib-2.0.0.dylib                 0x026b45cd g_main_loop_run + 1037
49  libgtk-quartz-2.0.0.dylib           0x02984a50 gtk_main + 240
50  ???                                 0x07ba37e4 0x0 + 129644516
51  ???                                 0x07ba37ac 0x0 + 129644460
52  ???                                 0x07ba378c 0x0 + 129644428
53  ???                                 0x02319534 0x0 + 36803892
54  ???                                 0x00758fe8 0x0 + 7704552
55  ???                                 0x00758de4 0x0 + 7704036
56  ???                                 0x00758eaa 0x0 + 7704234
57  libmonosgen-2.0.dylib               0x0015e672 mono_jit_runtime_invoke + 722
58  libmonosgen-2.0.dylib               0x002fae6a mono_runtime_invoke + 170
59  libmonosgen-2.0.dylib               0x002fd98c mono_runtime_exec_main + 620
60  libmonosgen-2.0.dylib               0x002fcbf1 mono_runtime_run_main + 929
61  libmonosgen-2.0.dylib               0x001ba3a5 mono_jit_exec + 149
62  libmonosgen-2.0.dylib               0x001bc939 mono_main + 9609
63  MonoDevelop                         0x000f7870 main + 2032
64  MonoDevelop                         0x000f60d5 start + 53
Comment 1 Anuj Bhatia 2012-08-30 17:46:05 UTC
Mono version: MonoFramework-MDK-2.10.10.macos10.xamarin.x86.dmg
MonoDevelop version: MonoDevelop-6a7c26c5fdb119dbad9bad7dea4e7165e5f751f7.dmg

Consistently re-produceable crash when launching auto-updater:

Process:         MonoDevelop [24538]
Path:            /Applications/MonoDevelop_Alpha/MonoDevelop.app/Contents/MacOS/MonoDevelop
Identifier:      com.xamarin.monodevelop
Version:         3.1.0 (3.1.0)
Code Type:       X86 (Native)
Parent Process:  launchd [261]
User ID:         501

Date/Time:       2012-08-30 14:27:57.374 -0700
OS Version:      Mac OS X 10.8.1 (12B19)
Report Version:  10

Interval Since Last Report:          357341 sec
Crashes Since Last Report:           4
Per-App Interval Since Last Report:  486 sec
Per-App Crashes Since Last Report:   1
Anonymous UUID:                      FD243C4E-F15F-4FBF-B1CF-49E355F3B9D3

Crashed Thread:  0  Dispatch queue: com.apple.main-thread

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000

Application Specific Information:
*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1007) creating CGSWindow'

Application Specific Backtrace 1:
0   CoreFoundation                      0x9a5917ab __raiseError + 219
1   libobjc.A.dylib                     0x9330b602 objc_exception_throw + 230
2   CoreFoundation                      0x9a4f123b +[NSException raise:format:] + 139
3   AppKit                              0x95bd845c _NXCreateWindowWithStyleMask + 302
4   AppKit                              0x95c6ef35 _NSCreateWindow + 57
5   AppKit                              0x95aecf73 -[NSWindow _commonAwake] + 2066
6   AppKit                              0x95aa9c77 -[NSWindow _commonInitFrame:styleMask:backing:defer:] + 1652
7   AppKit                              0x95aa8d3f -[NSWindow _initContent:styleMask:backing:defer:contentView:] + 1063
8   AppKit                              0x95aa8904 -[NSWindow initWithContentRect:styleMask:backing:defer:] + 70
9   AppKit                              0x9612124c -[NSWindow initWithContentRect:styleMask:backing:defer:screen:] + 79
10  libgdk-quartz-2.0.0.dylib           0x02181d40 -[GdkQuartzWindow initWithContentRect:styleMask:backing:defer:screen:] + 144
11  libgdk-quartz-2.0.0.dylib           0x0219b84f _gdk_window_impl_new + 1359
12  libgdk-quartz-2.0.0.dylib           0x0216bb49 gdk_window_new + 1369
13  libgtk-quartz-2.0.0.dylib           0x01ef5942 gtk_window_realize + 962
14  libgobject-2.0.0.dylib              0x029a29df g_cclosure_marshal_VOID__VOID + 223
15  libgobject-2.0.0.dylib              0x029a09ce g_type_class_meta_marshal + 142
16  libgobject-2.0.0.dylib              0x029a05bf g_closure_invoke + 511
17  libgobject-2.0.0.dylib              0x029c0620 signal_emit_unlocked_R + 1616
18  libgobject-2.0.0.dylib              0x029bf8e6 g_signal_emit_valist + 2662
19  libgobject-2.0.0.dylib              0x029bfdb1 g_signal_emit + 65
20  libgtk-quartz-2.0.0.dylib           0x01ed93ff gtk_widget_realize + 495
21  libgtk-quartz-2.0.0.dylib           0x01ed93d5 gtk_widget_realize + 453
22  libgtk-quartz-2.0.0.dylib           0x01d3385b gtk_menu_popup + 1147
23  libgtk-quartz-2.0.0.dylib           0x01c58e9a gtk_combo_box_menu_popup + 362
24  libgtk-quartz-2.0.0.dylib           0x01c5be75 gtk_combo_box_menu_button_press + 245
25  libgtk-quartz-2.0.0.dylib           0x01d2aa7e _gtk_marshal_BOOLEAN__BOXED + 286
26  libgobject-2.0.0.dylib              0x029a05bf g_closure_invoke + 511
27  libgobject-2.0.0.dylib              0x029c0bbe signal_emit_unlocked_R + 3054
28  libgobject-2.0.0.dylib              0x029bf98c g_signal_emit_valist + 2828
29  libgobject-2.0.0.dylib              0x029bfdb1 g_signal_emit + 65
30  libgtk-quartz-2.0.0.dylib           0x01edc7ad gtk_widget_event_internal + 749
31  libgtk-quartz-2.0.0.dylib           0x01edbf9f gtk_widget_event + 319
32  libgtk-quartz-2.0.0.dylib           0x01d283a1 propagate_event_up + 97
33  libgtk-quartz-2.0.0.dylib           0x01d28757 propagate_event + 535
34  libgtk-quartz-2.0.0.dylib           0x01d28867 gtk_propagate_event + 247
35  libgtk-quartz-2.0.0.dylib           0x01d2695f gtk_main_do_event + 767
36  libgdk-quartz-2.0.0.dylib           0x0218e279 gdk_event_dispatch + 153
37  libglib-2.0.0.dylib                 0x01abed61 g_main_dispatch + 513
38  libglib-2.0.0.dylib                 0x01ac065b g_main_context_dispatch + 155
39  libglib-2.0.0.dylib                 0x01ac0c8a g_main_context_iterate + 1466
40  libglib-2.0.0.dylib                 0x01ac15cd g_main_loop_run + 1037
41  libgtk-quartz-2.0.0.dylib           0x01c6f8f5 gtk_dialog_run + 597
42  ???                                 0x11b55644 0x0 + 297096772
43  ???                                 0x11b55600 0x0 + 297096704
44  ???                                 0x11b55518 0x0 + 297096472
45  ???                                 0x11b54a98 0x0 + 297093784
46  ???                                 0x11b549d0 0x0 + 297093584
47  ???                                 0x11b549a4 0x0 + 297093540
48  ???                                 0x11b4f10c 0x0 + 297070860
49  ???                                 0x0ce3c51e 0x0 + 216253726
50  ???                                 0x0cd205ea 0x0 + 215090666
51  ???                                 0x02dc357c 0x0 + 47986044
52  libglib-2.0.0.dylib                 0x01ac2fa6 g_timeout_dispatch + 102
53  libglib-2.0.0.dylib                 0x01abed61 g_main_dispatch + 513
54  libglib-2.0.0.dylib                 0x01ac065b g_main_context_dispatch + 155
55  libglib-2.0.0.dylib                 0x01ac0c8a g_main_context_iterate + 1466
56  libglib-2.0.0.dylib                 0x01ac15cd g_main_loop_run + 1037
57  libgtk-quartz-2.0.0.dylib           0x01d25f50 gtk_main + 240
58  ???                                 0x0ce2ed34 0x0 + 216198452
59  ???                                 0x0ce2ebcc 0x0 + 216198092
60  ???                                 0x0ce2ebac 0x0 + 216198060
61  ???                                 0x019e2374 0x0 + 27140980
62  ???                                 0x009c0f90 0x0 + 10227600
63  ???                                 0x009c0d9c 0x0 + 10227100
64  ???                                 0x009c0e56 0x0 + 10227286
65  libmono-2.0.dylib                   0x0010d252 mono_jit_runtime_invoke + 722
66  libmono-2.0.dylib                   0x002a7c7a mono_runtime_invoke + 170
67  libmono-2.0.dylib                   0x002aa79c mono_runtime_exec_main + 620
68  libmono-2.0.dylib                   0x002a9a01 mono_runtime_run_main + 929
69  libmono-2.0.dylib                   0x0016a755 mono_jit_exec + 149
70  libmono-2.0.dylib                   0x0016cce9 mono_main + 9609
71  MonoDevelop                         0x000a6870 main + 2032
72  MonoDevelop                         0x000a50d5 start + 53
Comment 2 Kristian Rietveld (inactive) 2012-09-01 04:33:49 UTC
> A consistently reproducible crash occurs when showing the code completion
> window on any Mono version newer than the released Mono 2.10.9. The crash
> happens every time inside GdkQuartzWindow, and is sometimes preceded by the

Does this happen for everybody?  Does this happen with every project/solution or only certain solutions?

I cannot reproduce it. My impression from the trace and debug message is that a window with invalid size is created. If this is true, this is something GTK+ would have to guard for.
Comment 3 Bojan Rajkovic [MSFT] 2012-09-01 10:51:13 UTC
Two notes:

Kristian, it was constistently reproducible for me, and I presume it is for Anuj with his crash as well. However, in the meantime, I wiped my machine and installed a fresh OS X Mountain Lion and then installed Mono and MonoDevelop, and I've had no issues. This was on my MacBook Pro. I haven't tried on my iMac yet, but I will try sometime over the weekend and hope that I can reproduce it with a symbolicated build. 

I'm wondering if maybe something I installed didn't ship a bad GTK/Quartz? I can't think of any good reason. I didn't have GTK+ debug symbols due to a packaging issue with Mono, but if Anuj can still reproduce it, maybe he can install a symbolicated build (I think we have some now) and see what's going on in GTK+.
Comment 4 Bojan Rajkovic [MSFT] 2012-09-18 16:15:50 UTC
I can, again, reproduce this crash. I haven't installed any GTK/Quartz using apps, though I did update my Mono and MonoDevelop builds recently. 

The weirdest thing is, this bug goes away when running under GDB. Running gdb /Applications/MonoDevelop.app/Contents/MacOS/MonoDevelop leads to the crash not happening.

I can reproduce it with gdb --attach, but I still don't get symbols, which leads me to believe syms are still screwed up.
Comment 5 Mikayla Hutchinson [MSFT] 2012-10-26 13:29:16 UTC
*** Bug 8011 has been marked as a duplicate of this bug. ***
Comment 6 Mikayla Hutchinson [MSFT] 2012-10-26 13:32:07 UTC
*** Bug 7205 has been marked as a duplicate of this bug. ***
Comment 7 Frank A. Krueger 2012-10-31 16:00:54 UTC
I can confirm that running 

$ gdb /Applications/Xamarin\ Studio.app/Contents/MacOS/MonoDevelop

makes the problem go away. Otherwise it is reliably reproduced.
Comment 8 Frank A. Krueger 2012-11-01 14:50:32 UTC
I just bought a new computer, did a clean install of Mono 3.0 and MD (wrench), and the problem persists.
Comment 9 Justin Ferrell 2012-11-05 09:35:11 UTC
Same issue. 'gdb' didn't fix. Acts fine opening and closing solutions/files, selecting text. Crashes as soon as I try to enter a character into the source editor.
Comment 10 Bojan Rajkovic [MSFT] 2012-11-26 00:55:23 UTC
I'm not able to see this anymore—is anyone else seeing it still?
Comment 11 Mikayla Hutchinson [MSFT] 2012-11-29 19:12:09 UTC
*** Bug 8647 has been marked as a duplicate of this bug. ***
Comment 12 Mikayla Hutchinson [MSFT] 2012-12-04 20:10:53 UTC
*** Bug 8751 has been marked as a duplicate of this bug. ***
Comment 13 Kristian Rietveld (inactive) 2012-12-05 04:42:12 UTC
Some googling on "Error (1007) creating CGSWindow" gives that this exception is apparently thrown when communication with the window server and indicates either:

 - The system being out of resources (http://lists.apple.com/archives/cocoa-dev/2009/Jan/msg01086.html)

 - Creating an NSWindow with invalid frame rect (http://stackoverflow.com/questions/4043371/create-nswindow-from-worker-thread-crash  and  http://www.cocoabuilder.com/archive/cocoa/96194-creating-window-without-ib.html#96193)


This likely confirms my suspicion of a window with invalid size in comment 2, I think we should figure a way to artificially raise this condition so we can put guards in place. Though, secondly we would have to figure out when exactly this is caused on MonoDevelop.
Comment 14 Matthias Fuchs 2012-12-11 02:49:05 UTC
I tried the trick with gdb and it works. There is no crash.
For now this is short-time solution for me, but this bug has to be fixed!
Comment 15 Kristian Rietveld (inactive) 2012-12-15 06:05:16 UTC
The crash can occur if a GdkWindow is created with attributes->height or attributes->width being an extremely large value (or uninitialized garbage which is a positive number). GDK already guards for width, height being smaller than 1. Because _NXCreateWindowWithStyleMask is present in the trace, the window being created has window type GDK_WINDOW_TEMP, which likely is a GTK_WINDOW_POPUP.

Now the question is when these invalid parameters are passed in exactly.
Comment 16 Kristian Rietveld (inactive) 2012-12-15 06:33:12 UTC
In the traces related to this bug I have seen, the GdkWindow is created from gtk_window_realize. gtk_window_realize always sets the width and height attributes to widget->allocation.{width,height}. It ensures a size request/allocate is done before the window is created. All widgets have their allocations properly initialized in gtk_widget_init().

So, the most probable cause is likely a size request routine returning a very large value. This is either due to a bug, or due to the size request depending on user data (i.e. very large text strings).
[Of course, there's still the option that something else is causing window creation to fail, for example the system being out of resources].


In GDK, we can either:

   * Apply a maximum bound to window width, height and create the window anyway (which will give you a big useless window).

   * Guard for very large window width, height values and refuse the create the window.

   * Actually catch and handle NSExceptions created by window creation.

In the last two cases the window is not created, which will likely leave the program in a troublesome state.
And, neither of these will fix the actual problem.
Comment 17 Kristian Rietveld (inactive) 2012-12-15 06:34:10 UTC
Is there the possibility that MonoDevelop creates popup windows, either from a menu or the code completion window that will contain very large text strings that could cause this problem?
Comment 18 Kristian Rietveld (inactive) 2012-12-15 06:49:14 UTC
For the record, on my machine window creation starts to occur if width * height comes close to 0x10000000.  0x4000 * 0x4000 does NOT work, 0x3900 * 0x4000 does work.  (I guess values are being rounded up for texture creation).

Your mileage may vary, something like 589824 * 100 also seems an upper bound though it does not come near 0x10000000.
Comment 19 Lluis Sanchez 2012-12-17 06:56:14 UTC
I don't think MD creates such a big popup windows.
Comment 20 Matthias Fuchs 2012-12-17 10:08:01 UTC
Since a few days I have a third monitor (USB-VGA) connected to my macbook pro.

Everytime I startup MD, the main windows has the full width of all 3 monitors combined (~4400px). I have to resize the window to fit the main monitor. This setting gets lost if I close MD.

I will try to disconnect my usb vga and see if the problem still occurs.
Comment 21 Mikayla Hutchinson [MSFT] 2012-12-17 13:33:42 UTC
Note that this has also been reported with context menus. Maybe it has something to do with our GetUsableMonitorGeometry logic?
Comment 22 Matthias Fuchs 2012-12-18 01:29:07 UTC
With the usb vga disconnected MD works correctly!
How can I check what resolution ist being reported with GetUsableMonitorGeometry?
Is there any way to debug this.

Btw, there are many issues with usb vga adapters and Mountain Lion. The performance is poor and there are quite many bugs (like wrong mouse cursors, screen parts that are not redrawn etc).
Comment 23 Curtis Wensley 2012-12-18 01:41:11 UTC
I have the issue when connecting a monitor via display port->dvi as well, so might not be due to issues with usb vga adapters per se, just external monitors?
Comment 24 Matthias Fuchs 2012-12-18 02:51:26 UTC
My main monitor is also connected via display port adapter (to hdmi) and I don't have any problems with that.

I will play around with the code from here: https://groups.google.com/forum/?fromgroups=#!topic/mono-svn-patches/MxqqIE33cbs
Maybe I can find a solution.
Comment 25 Kristian Rietveld (inactive) 2013-01-13 14:34:44 UTC
From what I can see, in most cases data from GetUsableMonitorGeometry is only used to determine the (x, y) coordinates. My assumption is that very large values of (x, y) coordinates (either positive or negative) cannot cause the crash. Neither can negative width, height, but very large positive width and height can trigger the exception.

If the width, height of a screen are always positive, I don't think GetUsableMonitorGeometry can cause trouble in the two cases the width/height returned are used in determining the width/height of a popup window.

Bojan indicated that the problems are sometimes preceded by 

8/21/12 12:37:56.070 PM MonoDevelop[38605]: CGSNewWindowWithOpaqueShape:
Malformed reigon

(the typo actually does exist in the CoreGraphics code, which is useful to find the exact place where this error is emitted :) ).

This error is emitted before attempting to create the window, so, before problems would arise because of very large window width/height. It is thus possible that something else can be wrong in the given input data.

I am currently in the process of trying to figure out the exact conditions under which these exceptions occur. This is a long and slow process unfortunately. Hopefully it will give us some more hints. Also, I will be double checking that the GDK code will never create a screen structure with negative or very large width/height values.



If anybody finds a reliable way to reproduce this crash, I would still be very much interested in that!
Comment 26 Matthias Fuchs 2013-01-13 15:55:15 UTC
For me this is reproducible to 100% by using my displaylink usb vga adapter. When there is this usb display is set up MD always crashes as described above. Maybe there is a chance for you to grab such a usb device or you can tell me what to do and I will try to find out more about his bug.
Comment 27 Kristian Rietveld (inactive) 2013-01-13 16:18:05 UTC
Matthias: good to know you have a 100% reproducibility success rate.  I am interesting in the exact arrangements of monitors you are using.  During the week, I will try to create a small program you can run that will give the exact coordinates of the monitor arrangement you are using. I hope this will then give us a hint whether these coordinates can result in "wrong" window widths and heights somewhere in GTK+/GDK.  Or maybe it will help me arrange my external monitor such that I can reproduce the problem as well.
Comment 28 Kristian Rietveld (inactive) 2013-01-20 15:00:54 UTC
Created attachment 3247 [details]
C code to display monitor configuration

Matthias: Could you please compile and run the attachment C program with the monitor configuration that crashes MonoDevelop?
Comment 29 Matthias Fuchs 2013-01-23 06:03:39 UTC
This is what i get without the third monitor attached:
Monitor 0: (0.000000, 0.000000)  1920.000000x1080.000000
Monitor 1: (1920.000000, 180.000000)  1440.000000x900.000000

This is the 3rd monitor connected (monitor 2)
Monitor 0: (0.000000, 0.000000)  1920.000000x1080.000000
Monitor 1: (3000.000000, 180.000000)  1440.000000x900.000000
Monitor 2: (1920.000000, -451.000000)  1080.000000x1920.000000
Comment 30 Matthias Fuchs 2013-01-23 06:15:49 UTC
I moved around my screes (in the system settings) and now monodevelop doesn't crash anymore (mono 3.0.2 and MD 3.1.1).

But I'm pretty sure I didn't upgrade any of these 2 components.
I didn't use the third monitor for a while now, because of the constant crashing, only to find it working now ...
Comment 31 Kristian Rietveld (inactive) 2013-01-23 06:18:56 UTC
Thanks Matthias.  The printed configuration, is that from before or after moving around the screens?
Comment 32 Matthias Fuchs 2013-01-23 06:32:52 UTC
fom before. i didn't try MD thought because I expected it not to work ... sorry my fault.
Comment 33 Kristian Rietveld (inactive) 2013-01-27 10:29:12 UTC
According to my pen and paper calculations, GDK correctly translates the given monitor configuration into a GDK monitor configuration. Also GetUsableMonitorGeometry in MonoDevelop should not be at fault.

Will need to think about where else things could go wrong.
Comment 34 luketheobscure 2013-02-13 16:53:28 UTC
I'm also getting this error. It is 100% reproducible. I'm running two monitors, one off of my thunderbolt connection.
Comment 35 Kristian Rietveld (inactive) 2013-02-13 16:54:49 UTC
Luke: could you run the code posted in comment 28 with your dual monitor configuration active?
Comment 36 luketheobscure 2013-02-13 17:01:18 UTC
Monitor 0: (0.000000, 0.000000)  1920.000000x1080.000000
Monitor 1: (-1440.000000, 0.000000)  1440.000000x900.000000
Comment 37 luketheobscure 2013-02-13 17:03:22 UTC
MonoDevelop 3.0.6
OSX 10.8.2
MacBook Pro Retina, Mid 2012
Comment 38 Kristian Rietveld (inactive) 2013-02-13 17:08:07 UTC
The monitor configuration is nothing out of the ordinary.  Could you perhaps check in Console.app if you can see any error message/diagnostic that could be related to MonoDevelop around the time you triggered the problem?  It might be worth checking windowserver.log in Console.app as well.  Thanks!
Comment 39 luketheobscure 2013-02-13 17:12:53 UTC
Nothing substantially different than what's in the crash logs.

Crash log excerpt:
"*** Terminating app due to uncaught exception 'NSInternalInconsistencyException', reason: 'Error (1007) creating CGSWindow'"

Console excerpt:
2/13/13 2:08:54.727 PM MonoDevelop[3204]: CGSNewWindowWithOpaqueShape: Malformed reigon
Comment 40 luketheobscure 2013-02-14 12:56:08 UTC
Just tested on the beta version 3.1.1 and it didn't crash (yet).
Comment 41 Kristian Rietveld (inactive) 2013-02-17 11:53:36 UTC
So if I understand correctly, both Matthias and Luke are not seeing the problem anymore on MD 3.1.1?
Comment 42 Mikayla Hutchinson [MSFT] 2013-02-17 18:21:31 UTC
Might have been stack corruption from another since-fixed bug, I suppose.

Let's needinfo this for a while, to find out whether anyone gets it with 3.1.1+.
Comment 43 Bojan Rajkovic [MSFT] 2013-04-03 18:16:55 UTC
I haven't seen this in months and months now. Marking as resolved fixed (in agreement with comment 42) until someone reports it again.