GNOME Bugzilla – Bug 714341
if Geary launches another application, closing Geary will close the other application
Last modified: 2019-03-31 14:07:42 UTC
---- Reported by chaz@yorba.org 2012-08-23 12:33:00 -0700 ---- Original Redmine bug id: 5705 Original URL: http://redmine.yorba.org/issues/5705 Searchable id: yorba-bug-5705 Original author: Charles Lindsay Original description: If I open Geary without a browser open, then click on a link in an email so Geary launches a browser, if I then close Geary the browser closes also. _All tabs_ close, which is troubling since I may have opened other tabs since clicking the link. This happens regardless of what browser you have set as default in system settings -- Geary will close Firefox, Chromium, or anything else. (In the case of Chromium, it sometimes crashes instead of cleanly exiting, but I believe this to be a bug in Chromium; see below.) Relatedly, if you don't have a text editor open, and then view source on a message, when Geary closes so will the launched text editor. Click on a PDF attachment to launch it, close Geary: the PDF viewer closes too. I believe we just have an issue with how we're launching external programs. I'm guessing the current behavior is due to Geary being erroneously treated as the parent process of the launched one. * * * **Old description, which I now believe to simply be a combination of this bug and a problem inside Chromium:** Very occasionally, when I close Geary, Chromium will then close, most often with SIGABRT (though anecdotally I've seen it happen where it closes without error). Geary has no issues, exiting without error. Oddly, Chromium generates a core file inside the directory I'm running Geary from. When I fire up Chromium under gdb with the core file, here's what it says: ... Core was generated by `/usr/lib/chromium-browser/chromium-browser https://docs.google.com/a/yorba.org/'. Program terminated with signal 6, Aborted. ... (gdb) bt #0 0x00007f1879f88445 in __GI_raise (sig=<optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007f1879f8bbab in __GI_abort () at abort.c:91 #2 0x00007f187a8d669d in __gnu_cxx::__verbose_terminate_handler () at ../../../../src/libstdc++-v3/libsupc++/vterminate.cc:95 #3 0x00007f187a8d4846 in __cxxabiv1::__terminate (handler=<optimized out>) at ../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:40 #4 0x00007f187a8d4873 in std::terminate () at ../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:50 #5 0x00007f187a8d528f in __cxxabiv1::__cxa_pure_virtual () at ../../../../src/libstdc++-v3/libsupc++/pure.cc:50 #6 0x00007f1880d81af2 in base::MessagePumpGtk::WillProcessEvent(_GdkEvent*) () #7 0x00007f1880d81b99 in base::MessagePumpGtk::DispatchEvents(_GdkEvent*) () #8 0x00007f187dfeccac in ?? () from /usr/lib/x86_64-linux-gnu/libgdk-x11-2.0.so.0 #9 0x00007f187e8c4d53 in g_main_dispatch (context=0x7f1885276790) at /build/buildd/glib2.0-2.32.3/./glib/gmain.c:2539 #10 g_main_context_dispatch (context=0x7f1885276790) at /build/buildd/glib2.0-2.32.3/./glib/gmain.c:3075 #11 0x00007f187e8c50a0 in g_main_context_iterate (dispatch=1, block=<optimized out>, context=0x7f1885276790, self=<optimized out>) at /build/buildd/glib2.0-2.32.3/./glib/gmain.c:3146 #12 g_main_context_iterate (context=0x7f1885276790, block=<optimized out>, dispatch=1, self=<optimized out>) at /build/buildd/glib2.0-2.32.3/./glib/gmain.c:3083 #13 0x00007f187e8c549a in g_main_loop_run (loop=0x7f1888fe15c0) at /build/buildd/glib2.0-2.32.3/./glib/gmain.c:3340 #14 0x00007f187e4ae9a8 in gtk_clipboard_store () from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0 #15 0x00007f1880c4eaf4 in BrowserProcessImpl::~BrowserProcessImpl() () #16 0x00007f1880c4ed79 in BrowserProcessImpl::~BrowserProcessImpl() () #17 0x00007f1880840da8 in browser_shutdown::ShutdownPostThreadsStop(bool) () #18 0x00007f1880b68a76 in ChromeBrowserMainParts::PostDestroyThreads() () #19 0x00007f188227f9a4 in content::BrowserMainLoop::ShutdownThreadsAndCleanUp() () #20 0x00007f188227ff6b in content::BrowserMainLoop::RunMainMessageLoopParts(bool*) () #21 0x00007f188227eb02 in BrowserMain(content::MainFunctionParams const&) () #22 0x00007f1880d1d378 in content::ContentMain(int, char const**, content::ContentMainDelegate*) () #23 0x00007f18804ba968 in ChromeMain () #24 0x00007f18804b8e06 in main () Yes, it appears that it's somehow related to the clipboard (I should also mention that I have ClipIt installed, a GTK clipboard manager). My guess is that it's not the fault of Geary, but something in the GTK stack or Chromium itself that's going haywire. Not sure why a Chromium process is even closing when Geary closes, or why it seems to be related to the Geary process (hence dumping core inside my Geary repo), or how one Chromium process getting a SIGABRT will bring down all my browser windows and tabs. Related issues: related to geary - 7251: Behavior when clicking links (Open) related to geary - 7559: Mouse cursor switches to busy state after opening new win... (Invalid) ---- Additional Comments From geary-maint@gnome.bugs 2013-08-15 17:36:00 -0700 ---- ### History #### #1 Updated by Charles Lindsay about 1 year ago I've put the generated core file from this run in geary-debug/5705 on kermie/share. #### #2 Updated by Adam Dingle about 1 year ago * **Priority** changed from _Normal_ to _High_ I bet that Chromium is your default browser and you launched it by clicking a link in Geary. That might explain why the core dump is in the directory you ran Geary from - that's likely the working directory for the Chromium process too. #### #3 Updated by Charles Lindsay about 1 year ago * **Subject** changed from _[norepro] closing Geary will occasionally cause Chromium to crash with SIGABRT_ to _closing Geary will occasionally cause Chromium to close (usually with SIGABRT)_ I can reproduce one case of this problem reliably: 1. Make sure no chromium processes are running 2. Run Geary 3. Click a link in an email to launch a Chromium browser 4. Close Geary 5. Note that the Chromium browser closes as well Last time this happened (though I haven't tested it again since) I had opened several more tabs and windows, and they **all** closed with Geary. Also notable is that this isn't crashing Chromium from what I can tell; it's as if the desktop thinks the Chromium window is a child of the Geary window, so it gets closed along with its parent. This is not the behavior I expect, either way. #### #4 Updated by Jim Nelson about 1 year ago * **Category** set to _client_ * **Priority** changed from _High_ to _Urgent_ Marking as urgent because this results in crashes and now it appears that Geary can disrupt another process. We should attempt to reproduce this on other machines. #### #5 Updated by Charles Lindsay about 1 year ago I've tried the same steps in other apps (thunderbird, the about box in gedit, libreoffice writer), and none of them bring down Chromium when they exit. #### #6 Updated by Charles Lindsay about 1 year ago Another twist: if I set my default browser to firefox, I see the exact same behavior: closing Geary closes firefox. #### #7 Updated by Jim Nelson 10 months ago * **Target version** set to _0.3.0_ #### #8 Updated by Jim Nelson 9 months ago * **Priority** changed from _Urgent_ to _High_ #### #9 Updated by Jim Nelson 9 months ago * **Target version** changed from _0.3.0_ to _0.4.0_ #### #10 Updated by Jim Nelson 8 months ago * **Target version** changed from _0.4.0_ to _0.5.0_ #### #11 Updated by Charles Lindsay 6 months ago * **Subject** changed from _closing Geary will occasionally cause Chromium to close (usually with SIGABRT)_ to _if Geary launches another application, closing Geary will close the other application_ * **Description** updated (diff) #### #12 Updated by Jim Nelson 6 months ago I can't reproduce this. Let's try on some other machines in the office and see if we can get another repro case. #### #13 Updated by Charles Lindsay 6 months ago I'll mention I'm on regular ol' Ubuntu (i.e. not Kubuntu etc.) Raring, running Unity. It also happened for me on regular ol' Quantal. #### #14 Updated by Brendan Long 3 months ago I don't see this with Fedora 19 and Firefox or GNOME's "Web". Is it possible that it's a glib or GTK+ bug that was fixed? With the cases of Gtk.show_uri, it may be interesting to see what happens if you set the [first parameter](https://developer.gnome.org/gtk3/3.0/gtk3 -Filesystem-utilities.html#gtk-show-uri) to null, or what happens if you replace it with [g_app_info_launch_default_for_uri](https://developer.gnome.or g/gio/2.32/GAppInfo.html#g-app-info-launch-default-for-uri). I would test myself if I could repro. --- Bug imported by chaz@yorba.org 2013-11-21 20:26 UTC --- This bug was previously known as _bug_ 5705 at http://redmine.yorba.org/show_bug.cgi?id=5705 Unknown milestone "unknown in product geary. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one. Resolution set on an open status. Dropping resolution
This still shows up for me on ubuntu saucy. It's been particularly annoying lately because of gedit. If I open gedit from the console, I get a warning: ** (gedit:20919): WARNING **: Could not load Gedit repository: Typelib file for namespace 'GtkSource', version '3.0' not found If gedit wasn't already open and I view source on a message in Geary, I see the same warning. However, if I'm running with fatal warnings (as I often do), that warning brings down *Geary*.
Charles can reproduce this consistently, so we should take a hard look at this for 0.6.
As soon as I sat down to try to reproduce this, I stopped being able to. I looked into the code, and there is certainly a code path where the process will be fork/exec'd instead of launched via dbus (see https://git.gnome.org/browse/glib/tree/gio/gdesktopappinfo.c?id=2.38.2#n1557). So, I might not be crazy. It looks like what's happening is it's looking for the default app to handle the URI (https://git.gnome.org/browse/glib/tree/gio/gappinfo.c?id=2.38.2#n681). If that GAppInfo is filled out correctly (it needs the app_id, specifically), it looks like glib will try to use dbus. If it doesn't, it'll spawn the process manually. It's a bit hard to tell how the GAppInfo struct is getting filled out, but it appears to have to do with the .desktop file registry. So, there could be any number of things going on. It could be a legitimate bug that was fixed recently (and I just messed up last week in my last comment). It could be something was borked with my desktop file registry. It could be lots of things. I got as far as looking up the GAppInfo that handles the URI and checking its ID before realizing I couldn't reproduce the issue. If anyone wants to test, insert this code before any call to Gtk.show_uri(): string scheme = Uri.parse_scheme(uri); AppInfo info = AppInfo.get_default_for_uri_scheme(scheme); if (info == null) info = File.new_for_uri(uri).query_default_handler(); stdout.printf("%s (%s): %s\n", uri, scheme, info.get_id()); That's a place to start if anyone can reproduce the issue. That'll give us a hint about what GTK is doing in show_uri().
Cannot reproduce this with 3.32.