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.
1) Click on Open Solution or File on the Welcome Page
2) Drag any file/directory displayed in dialog around the place and release the mouse
3) Exception and complete hang
WARNING [2011-10-28 11:28:42Z]: GLib-Warning: g_main_context_prepare(): main loop already active in another thread
at MonoMac.AppKit.NSOpenPanel.RunModal(System.String directory, System.String fileName, System.String types) in /Users/michael/Mono/monomac/src/AppKit/NSOpenPanel.g.cs:line 146
at MonoDevelop.MacIntegration.MacSelectFileDialogHandler.RunPanel(MonoDevelop.Components.Extensions.SelectFileDialogData data, MonoMac.AppKit.NSSavePanel panel) in /Users/alanmcgovern/Projects/monodevelop/main/src/addins/MacPlatform/Dialogs/MacSelectFileDialogHandler.cs:line 125
at MonoDevelop.MacIntegration.MacOpenFileDialogHandler.Run(MonoDevelop.Ide.Extensions.OpenFileDialogData data) in /Users/alanmcgovern/Projects/monodevelop/main/src/addins/MacPlatform/Dialogs/MacOpenFileDialogHandler.cs:line 167
at MonoDevelop.Components.Extensions.PlatformDialog`1[[MonoDevelop.Ide.Extensions.OpenFileDialogData, MonoDevelop.Ide, Version=220.127.116.11, Culture=neutral, PublicKeyToken=null]].Run() in /Users/alanmcgovern/Projects/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Components.Extensions/PlatformDialog.cs:line 98
at MonoDevelop.Components.Extensions.SelectFileDialog`1[[MonoDevelop.Ide.Extensions.OpenFileDialogData, MonoDevelop.Ide, Version=18.104.22.168, Culture=neutral, PublicKeyToken=null]].Run() in /Users/alanmcgovern/Projects/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Components.Extensions/ISelectFileDialog.cs:line 297
at MonoDevelop.Ide.Commands.OpenFileHandler.Run() in /Users/alanmcgovern/Projects/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.Commands/FileCommands.cs:line 87
at MonoDevelop.Components.Commands.CommandHandler.Run(System.Object dataItem) in /Users/alanmcgovern/Projects/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Components.Commands/CommandHandler.cs:line 61
at MonoDevelop.Components.Commands.CommandHandler.InternalRun(System.Object dataItem) in /Users/alanmcgovern/Projects/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Components.Commands/CommandHandler.cs:line 42
at MonoDevelop.Components.Commands.CommandManager.DefaultDispatchCommand(MonoDevelop.Components.Commands.ActionCommand cmd, MonoDevelop.Components.Commands.CommandInfo info, System.Object dataItem, System.Object target, CommandSource source) in /Users/alanmcgovern/Projects/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Components.Commands/CommandManager.cs:line 649
at MonoDevelop.Components.Commands.CommandManager.DispatchCommand(System.Object commandId, System.Object dataItem, System.Object initialTarget, CommandSource source) in /Users/alanmcgovern/Projects/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Components.Commands/CommandManager.cs:line 619
at MonoDevelop.Components.Commands.CommandManager.DispatchCommand(System.Object commandId, CommandSource source) in /Users/alanmcgovern/Projects/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Components.Commands/CommandManager.cs:line 518
at MonoDevelop.Ide.WelcomePage.WelcomePageLinkButton.DispatchLink(System.String uri) in /Users/alanmcgovern/Projects/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.WelcomePage/WelcomePageLinkButton.cs:line 215
at MonoDevelop.Ide.WelcomePage.WelcomePageLinkButton.OnClicked() in /Users/alanmcgovern/Projects/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide.WelcomePage/WelcomePageLinkButton.cs:line 199
at Gtk.Button.clicked_cb(IntPtr button)
at MonoDevelop.Ide.IdeApp.Run() in /Users/alanmcgovern/Projects/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide/Ide.cs:line 384
at MonoDevelop.Ide.IdeStartup.Run(System.String args) in /Users/alanmcgovern/Projects/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide/IdeStartup.cs:line 282
at MonoDevelop.Ide.IdeStartup.Main(System.String args) in /Users/alanmcgovern/Projects/monodevelop/main/src/core/MonoDevelop.Ide/MonoDevelop.Ide/IdeStartup.cs:line 545
at MonoDevelop.Startup.MonoDevelopMain.Main(System.String args) in /Users/alanmcgovern/Projects/monodevelop/main/src/core/MonoDevelop.Startup/MonoDevelop.Startup/MonoDevelopMain.cs:line 16
^Cmake: *** [runmd] Interrupt: 2
make: *** [run] Interrupt: 2
*** Bug 2537 has been marked as a duplicate of this bug. ***
I can reproduce this. It seem that GTK is interfering with the drop in a cocoa dialog.
Here is the relevant portion of backtrace from here.
Thread 1 (process 38046):
#0 0x989cbd49 in read$UNIX2003 ()
#1 0x036a17c4 in g_main_context_check ()
#2 0x03e885e9 in run_loop_after_waiting ()
#3 0x03e88720 in run_loop_observer_callback ()
#4 0x98d4247e in __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ ()
#5 0x98d423bd in __CFRunLoopDoObservers ()
#6 0x98d14e19 in __CFRunLoopRun ()
#7 0x98d1447c in CFRunLoopRunSpecific ()
#8 0x98d14328 in CFRunLoopRunInMode ()
#9 0x938af4e3 in -[NSRunLoop(NSRunLoop) runMode:beforeDate:] ()
#10 0x9393be76 in -[NSRunLoop(NSRunLoop) runUntilDate:] ()
#11 0x9875164b in TDragOperation::DoFlockingDrag ()
#12 0x986f2edf in -[NSView(FI_NSViewAdditions) FI_dragWithPasteboardCommon:event:localMouseDownLocation:initialTargetContainer:nodes:itemBoundsMap:itemAnchorsMap:image:offset:source:] ()
#13 0x986f30b9 in -[NSView(FI_NSViewAdditions) FI_dragWithPasteboardCommon:event:initialTargetContainer:nodes:itemBoundsMap:itemAnchorsMap:image:offset:source:] ()
#14 0x986f3258 in -[NSView(FI_NSViewAdditions) FI_dragWithPasteboard:event:initialTargetContainer:nodes:itemBoundsMap:itemAnchorsMap:image:offset:source:] ()
#15 0x98771949 in -[FI_TBrowserViewController(DragNDrop) dragImage:offset:event:nodes:pasteboard:source:] ()
#16 0x98771821 in -[FI_TBrowserViewController(DragNDrop) dragImage:offset:event:pasteboard:source:] ()
#17 0x9878bf66 in -[FI_TListView dragImage:at:offset:event:pasteboard:source:slideBack:] ()
#18 0x925e3626 in -[NSTableView _doImageDragUsingRowsWithIndexes:event:pasteboard:source:slideBack:startRow:] ()
#19 0x925e3203 in -[NSTableView __doImageDragUsingRowsWithIndexes:event:pasteboard:source:slideBack:startRow:] ()
#20 0x925df352 in -[NSTableView _performClassicDragOfIndexes:hitRow:event:] ()
#21 0x92124597 in -[NSTableView _performDragFromMouseDown:] ()
#22 0x92122c9d in -[NSTableView mouseDown:] ()
#23 0x92501465 in -[NSOutlineView mouseDown:] ()
#24 0x9878aed5 in -[FI_TListView mouseDown:] ()
#25 0x92085ca5 in -[NSWindow sendEvent:] ()
#26 0x9201e0e7 in -[NSApplication sendEvent:] ()
#27 0x92287dfe in -[NSApplication _modalSession:sendEvent:] ()
#28 0x922879c8 in -[NSApplication _realDoModalLoop:peek:] ()
#29 0x92282c1d in -[NSApplication _doModalLoop:peek:] ()
#30 0x922876a4 in -[NSApplication runModalForWindow:] ()
#31 0x9255d480 in -[NSSavePanel runModal] ()
#32 0x9255a075 in -[NSSavePanel runModalForDirectory:file:types:] ()
#33 0x13dcc940 in ?? ()
*** Bug 2693 has been marked as a duplicate of this bug. ***
*** Bug 1222 has been marked as a duplicate of this bug. ***
I think we are hitting the case mentioned in the big comment
section at the start of gdkeventloop-quartz.c:
* The main known limitation of this code is that if a callback is triggered
* via the OS X run loop while we are "polling" (in either case described
* above), iteration of the GLib main loop is not possible from within
* that callback. If the programmer tries to do so explicitly, then they
* will get a warning from GLib "main loop already active in another thread".
Will consult with Owen how to resolve this.
I forwarded the issue to an upstream bug report:
We have been adding some more comments to the upstream bug. For now, we have observed that an NSOpenPanel launched from a C test case works perfectly fine and does not exhibit this issue. However, a similar C# test case which launches an NSOpenPanel breaks.
I suspect Mono is somehow interfering in the main loops. I will try to dig up more details. Test cases can be found in the upstream bug.
Okay, seems I was a bit off. It is not a mono issue. The status is as follows, I tested the C test case using several glib branches:
master: works fine
glib-2-30: works fine
glib-2-28: breaks (this is what Mono ships).
Given that recent Pango and gdk-pixbuf (these are also used with gtk-2-24) all require something more recent than glib-2-28, I don't think we should spend any time trying to fix this differently.
Therefore, we strongly recommend to upgrade glib, but this has to be done with caution. glib-2-30 should be safe on OS X. If Xamarin opts to upgrade to master/glib-2-32, then we *must* patch glib/gatomic.c otherwise the users will definitely experience a performance regression.
I am aware that pango master and gdk-pixbuf master both require glib 2.31.x. If I am not mistaken this is due to the new deprecation macros. I guess we could simply have a patch to revert this in pango and gdk-pixbuf if we want to use glib-2-30 for now in combination with pango master and gdk-pixbuf master.
Yes, we already have a patch for Pango to revert the deprecation macros and glib requirement bump.
I'd like to upgrade glib but we have a glib patchset from macports we'd have to upgrade too, so it'll need a bit of work.
*** Bug 2472 has been marked as a duplicate of this bug. ***
Yes, seems to work with glib 2.30, though we still get the glib warning.
We'll need to update to 2.32 at some point, how complex will that patch be?
> We'll need to update to 2.32 at some point, how complex will that patch be?
It depends on which compiler you are using for your development and production builds. Based on this compiler, it might be well possible to produce a patch to glib's configure.in to make an exception for the Apple compiler. At FOSDEM I managed to get glib to compile with the fast atomic operations by juggling around with defines, so that's why I think there are possibilities here.
A long term solution should be different though, and for OS X we need to start to think about adopting Clang I would say.
We're using the default compiler picked up by configure on Snow Leopard and Lion. We don't build on anything older than SL.
*** Bug 4771 has been marked as a duplicate of this bug. ***
FYI there is now an upstream bug for the atomic ops performance problem: https://bugzilla.gnome.org/show_bug.cgi?id=682818
Michael, if we want to update our glib we can do it with the patch in that bug report. Is this something we want to do within the next week or so or do we want to punt it til a less busy time?
I assume you asked Michael Hutchinson and not Natterer ;)
If this is a high priority for you guys, I can prioritize this and put some time in fixing up the patch in that upstream bug report, so that it can be upstreamed.
The patch appears to be in upstream but I'm holding off on upgrading until it's in a stable release.
I am removing this from my watch list as the compiler issue has been addressed upstream and an upgrade to newer glib should resolve the issue addressed by this bug.
Yup, seems to have worked.