Bug 1758 - [GTK] Complete hang if you drag a file in the OpenFile dialog
Summary: [GTK] Complete hang if you drag a file in the OpenFile dialog
Status: RESOLVED FIXED
Alias: None
Product: Xamarin Studio
Classification: Desktop
Component: General ()
Version: Trunk
Hardware: PC Mac OS
: Normal normal
Target Milestone: ---
Assignee: Mikayla Hutchinson [MSFT]
URL:
: 1222 2472 2537 2693 4771 ()
Depends on:
Blocks:
 
Reported: 2011-10-28 06:36 UTC by Alan McGovern
Modified: 2013-04-22 10:47 UTC (History)
7 users (show)

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

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 Alan McGovern 2011-10-28 06:36:00 UTC
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
Stack trace: 
   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=2.6.0.0, 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=2.6.0.0, 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 Gtk.Application.gtk_main()
   at Gtk.Application.Run()
   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[1]: *** [runmd] Interrupt: 2
make: *** [run] Interrupt: 2
Comment 1 Mikayla Hutchinson [MSFT] 2012-01-03 14:52:38 UTC
*** Bug 2537 has been marked as a duplicate of this bug. ***
Comment 2 Mikayla Hutchinson [MSFT] 2012-04-04 19:51:53 UTC
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 ?? ()
Comment 3 Mikayla Hutchinson [MSFT] 2012-04-04 19:54:34 UTC
*** Bug 2693 has been marked as a duplicate of this bug. ***
Comment 4 Mikayla Hutchinson [MSFT] 2012-04-04 19:59:54 UTC
*** Bug 1222 has been marked as a duplicate of this bug. ***
Comment 5 Michael Natterer 2012-04-12 07:47:01 UTC
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.
Comment 6 Michael Natterer 2012-04-14 12:02:09 UTC
I forwarded the issue to an upstream bug report:
https://bugzilla.gnome.org/show_bug.cgi?id=674109
Comment 7 Kristian Rietveld (inactive) 2012-04-21 07:45:32 UTC
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.
Comment 8 Kristian Rietveld (inactive) 2012-04-21 16:11:46 UTC
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.
Comment 9 Mikayla Hutchinson [MSFT] 2012-04-23 19:27:10 UTC
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.
Comment 10 Mikayla Hutchinson [MSFT] 2012-04-25 11:34:46 UTC
*** Bug 2472 has been marked as a duplicate of this bug. ***
Comment 11 Mikayla Hutchinson [MSFT] 2012-04-25 17:04:29 UTC
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?
Comment 12 Kristian Rietveld (inactive) 2012-04-26 05:57:24 UTC
> 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.
Comment 13 Mikayla Hutchinson [MSFT] 2012-04-27 15:43:44 UTC
We're using the default compiler picked up by configure on Snow Leopard and Lion. We don't build on anything older than SL.
Comment 14 Mikayla Hutchinson [MSFT] 2012-04-30 15:12:36 UTC
*** Bug 4771 has been marked as a duplicate of this bug. ***
Comment 15 Kristian Rietveld (inactive) 2013-01-12 10:10:29 UTC
FYI there is now an upstream bug for the atomic ops performance problem:  https://bugzilla.gnome.org/show_bug.cgi?id=682818
Comment 16 Alan McGovern 2013-01-14 09:49:04 UTC
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?
Comment 17 Kristian Rietveld (inactive) 2013-01-20 11:42:51 UTC
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.
Comment 18 Mikayla Hutchinson [MSFT] 2013-02-26 13:25:24 UTC
The patch appears to be in upstream but I'm holding off on upgrading until it's in a stable release.
Comment 19 Kristian Rietveld (inactive) 2013-04-20 08:17:48 UTC
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.
Comment 20 Mikayla Hutchinson [MSFT] 2013-04-22 10:47:24 UTC
Yup, seems to have worked.