GNOME Bugzilla – Bug 737811
Geary window does not open
Last modified: 2014-12-02 22:26:51 UTC
When launching geary for the first time, the window does not show. strace output spits out the following endlessly: poll([{fd=3, events=POLLIN}, {fd=9, events=POLLIN}, {fd=7, events=POLLIN}, {fd=13, events=POLLIN}, {fd=14, events=POLLIN}], 5, 0) = 0 (Timeout) futex(0x7fff0986aa30, FUTEX_WAKE, 1) = 0 futex(0x2721220, FUTEX_WAIT, 0, {0, 99999272}) = -1 ETIMEDOUT (Connection timed out) recvmsg(9, 0x7fff0986a720, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLIN}, {fd=9, events=POLLIN}, {fd=7, events=POLLIN}, {fd=13, events=POLLIN}, {fd=14, events=POLLIN}], 5, 0) = 0 (Timeout) futex(0x7fff0986aa30, FUTEX_WAKE, 1) = 0 futex(0x2721220, FUTEX_WAIT, 0, {0, 99999571}) = -1 ETIMEDOUT (Connection timed out) recvmsg(9, {msg_name(0)=NULL, msg_iov(1)=[{"U\2\247\0\2105\375\2\3\24\4\0\20\0\0\0\0\0\0\24\24\24\24\24\0\0\3\37%\2\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32 recvmsg(9, 0x7fff0986a720, 0) = -1 EAGAIN (Resource temporarily unavailable) When I keep the process running and launch geary again, the window opens, but the spinner loops endlessly. strace continues to output: poll([{fd=3, events=POLLIN}, {fd=9, events=POLLIN}, {fd=13, events=POLLIN}, {fd=7, events=POLLIN}, {fd=14, events=POLLIN}], 5, 0) = 0 (Timeout) recvmsg(9, 0x7fff48f0ba50, 0) = -1 EAGAIN (Resource temporarily unavailable) recvmsg(9, 0x7fff48f0ba50, 0) = -1 EAGAIN (Resource temporarily unavailable) recvmsg(9, 0x7fff48f0ba50, 0) = -1 EAGAIN (Resource temporarily unavailable) recvmsg(9, 0x7fff48f0a140, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=9, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=9, revents=POLLOUT}]) writev(9, [{"\22\0\n\0\4\0\0\3\233\1\0\0\6\0\0\0 \4\0\4\0\0\0\32\0\0\0\32\0\0\0"..., 1320}, {NULL, 0}, {"", 0}], 3) = 1320 recvmsg(9, {msg_name(0)=NULL, msg_iov(1)=[{"\34\0\257\27\4\0\0\3\233\1\0\0\262\335\376\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32 recvmsg(9, {msg_name(0)=NULL, msg_iov(1)=[{"\34\0\260\27\4\0\0\3\320\1\0\0\263\335\376\2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32 recvmsg(9, {msg_name(0)=NULL, msg_iov(1)=[{"A\0\267\27\341\5\0\3\3\0\202\0n\0\0\3\0 \34\0\0\0\0\0\0\0\0\0\0\0\0\0", 4096}], msg_controllen=0, msg_flags=0}, 0) = 32 recvmsg(9, 0x7fff48f0cb00, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLIN}, {fd=9, events=POLLIN}, {fd=13, events=POLLIN}, {fd=7, events=POLLIN}, {fd=14, events=POLLIN}], 5, 0) = 0 (Timeout) poll([{fd=3, events=POLLIN}, {fd=9, events=POLLIN}, {fd=13, events=POLLIN}, {fd=7, events=POLLIN}, {fd=14, events=POLLIN}], 5, 0) = 1 ([{fd=9, revents=POLLIN}]) recvmsg(9, {msg_name(0)=NULL, msg_iov(1)=[{"\301\0\320\27+\0\0\3\3\0\202\0\23\0\27\3\0 \34\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 96 recvmsg(9, 0x7fff48f0c9d0, 0) = -1 EAGAIN (Resource temporarily unavailable) recvmsg(9, 0x7fff48f0c9d0, 0) = -1 EAGAIN (Resource temporarily unavailable) recvmsg(9, 0x7fff48f0cb00, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLIN}, {fd=9, events=POLLIN}, {fd=13, events=POLLIN}, {fd=7, events=POLLIN}, {fd=14, events=POLLIN}], 5, 0) = 0 (Timeout) futex(0x7fff48f0ce10, FUTEX_WAKE, 1) = 0 futex(0x2526840, FUTEX_WAIT, 0, {0, 99999320}) = -1 ETIMEDOUT (Connection timed out) recvmsg(9, {msg_name(0)=NULL, msg_iov(1)=[{"\241 \354\27\4\0\0\3m\1\0\0\234\0\0\0\0\0\0\0SH\222\263\v\0\0\0\0\0\0\0"..., 4096}], msg_controllen=0, msg_flags=0}, 0) = 64 recvmsg(9, 0x7fff48f0cb00, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLIN}, {fd=9, events=POLLIN}, {fd=13, events=POLLIN}, {fd=7, events=POLLIN}, {fd=14, events=POLLIN}], 5, 0) = 0 (Timeout) poll([{fd=3, events=POLLIN}, {fd=9, events=POLLIN}, {fd=13, events=POLLIN}, {fd=7, events=POLLIN}, {fd=14, events=POLLIN}], 5, 0) = 0 (Timeout) recvmsg(9, 0x7fff48f0c9d0, 0) = -1 EAGAIN (Resource temporarily unavailable) recvmsg(9, 0x7fff48f0cb00, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLIN}, {fd=9, events=POLLIN}, {fd=13, events=POLLIN}, {fd=7, events=POLLIN}, {fd=14, events=POLLIN}], 5, 0) = 0 (Timeout) recvmsg(9, 0x7fff48f0cb00, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLIN}, {fd=9, events=POLLIN}, {fd=13, events=POLLIN}, {fd=7, events=POLLIN}, {fd=14, events=POLLIN}], 5, 0) = 0 (Timeout) recvmsg(9, 0x7fff48f0ba50, 0) = -1 EAGAIN (Resource temporarily unavailable) recvmsg(9, 0x7fff48f0ba50, 0) = -1 EAGAIN (Resource temporarily unavailable) recvmsg(9, 0x7fff48f0ba50, 0) = -1 EAGAIN (Resource temporarily unavailable) recvmsg(9, 0x7fff48f0a140, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=9, events=POLLIN|POLLOUT}], 1, 4294967295) = 1 ([{fd=9, revents=POLLOUT}]) writev(9, [{"\22\0\n\0\4\0\0\3\233\1\0\0\6\0\0\0 \4\0\4\0\0\0\32\0\0\0\32\0\0\0"..., 1320}, {NULL, 0}, {"", 0}], 3) = 1320 recvmsg(9, 0x7fff48f0cb00, 0) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLIN}, {fd=9, events=POLLIN}, {fd=13, events=POLLIN}, {fd=7, events=POLLIN}, {fd=14, events=POLLIN}], 5, 0) = 0 (Timeout) futex(0x7fff48f0ce10, FUTEX_WAKE, 1) = 0 OS: Arch Versions: geary 0.8.0-2 gmime 2.6.20-2 libcanberra 0.30-4 libcanberra-pulse 0.30-4 libgee 0.16.0-1 libnotify 0.7.6-1 webkitgtk 2.4.5-1 I have tried removing ~/.local/share/geary, no luck. Is there any other data folder I can try deleting?
What version of GTK+ are you using?
I believe this is the same thing that was reported on the Geary mailing list: https://mail.gnome.org/archives/geary-list/2014-October/msg00000.html The poster there noted that if he rolled back to GTK+ 3.12, Geary ran fine. That suggests there's some issue with GTK+ 3.14 (if you're using that version, tigrangaba, which I suspect you are). I've been unable to reproduce this on my GTK+ 3.14 instance (I'm running F21 Alpha in a VirtualBox instance). Let me do more investigation. Any clues you have for reproducing this would be welcome.
Yes, I am using gtk 3.14. I did try rolling back to 3.12 but I was having the same issue. I'm using Gnome Shell 3.14 also. I'm not sure if it is related to the DE and what DE F21 is using.
I ran with -d flag and I do get the same message as the one in the mailing list: [deb] 17:00:28 0.101792 null-indicator.vala:13: No messaging menu support in this build [deb] 17:00:28 0.017415 conversation-web-view.vala:207: Loading new message viewer style from /home/tigran/.config/geary/user-message.css... (geary:8010): Gtk-WARNING **: Symbolic icon close-symbolic is not in an icon theme directory [deb] 17:00:28 0.067557 db-versioned-database.vala:77: VersionedDatabase.upgrade: current database schema for /home/tigran/.local/share/geary/************@*****.com/geary.db:22 CPU is at 1.5%, but I suspect its because of the endless futux stuff strace is outputting. I think it is the same issue as the mailing list. If I delete the geary folder I get the new account dialog, but after that nothing. If I keep the process running and launch it again, the window shows, but the side bar is empty and the spinner loops endlessly. I'll keep the window open for longer see if anything happens.
Building from git myself works. I think it is the Arch package that is the issue (or maybe that it is built with gtk 3.12 libraries?). Installing geary-git from AUR works. I will let you update the status accordingly. Thank you.
If you could report your findings to the Arch people, it would be greatly appreciated. I'm going to close this bug; if you discover new information that suggests the problem does lie with Geary, please let me know and I'll reopen.
Is it possible this bug is the same as bug #720360? It sure sounds like it. In Preferences, do you have "Notify of new mail at startup" checked?
I did not have that checked. It does work whether it is on or off after I compiled it myself rather than using arch provided bin. I checked it now, and removed it, installed Arch's bin and the window did show. I unchecked that option, restarted geary, and the bug is back.
Huh. I'm more convinced than ever this is a conflict between bug #720360 and the new feature that has Geary notifying of mail in the background. That feature works by running Geary at login with its main window hidden. When you run Geary, all that really happens is the main window is made visible.' Let me keep looking at this.
For the life of me, I cannot reproduce this. I've tried a variety of approaches. I do know one thing, though. If I set up Geary to run at login (i.e. "Notify of new mail at startup"), clear my local mail database, logout, and then login again, Geary's welcome dialog will appear immediately. If Arch's (or another distro's) window manager is set up in such a way that this dialog is not visible/realized to the user at login, then bug #720360 will kick in when the user re-runs Geary: a blank main window making it look like Geary is not downloading mail. I've fixed bug #720360 in master. I don't *know* that that will solve this bug, but I'm hopeful. If anyone out there who can reliably reproduce this problem could try building from master and reproducing, I would be grateful.
Installing geary from git fixes for me (geary-git from AUR)
*** Bug 739115 has been marked as a duplicate of this bug. ***
(In reply to comment #11) > Installing geary from git fixes for me (geary-git from AUR) Same thing here, geary-git works fine.
*** Bug 737551 has been marked as a duplicate of this bug. ***
Ok, I'm going to close this. It looks like bug #720360 did indeed solve this.
I'm afraid I'm still seeing this - geary 0.8.2, just upgraded from GNOME 3.12 to GNOME 3.14 (on Gentoo) and the geary main window wouldn't show up. strace shows similar output to the original reporter. I also hooked in gdb and got a backtrace:
+ Trace 234378
Here's the backtrace for the other thread. This looks like a deadlock - the thread doing geary_synchronization_spin_waiter_wait() already has the mutex and is doing cond_wait() while the thread that is supposed to post the notification to the condition variable is trying to get the mutex.
+ Trace 234379
It appears that on glib 2.42 the mutex implementation in glib/gthread-posix.c was changed to use futex on linux (if present) which is likely exposing this issue. Indeed I was able to work around (got geary to properly start up) using the following (obviously not correct code) patch: --- a/src/engine/util/util-synchronization.vala +++ b/src/engine/util/util-synchronization.vala @@ -90,12 +90,12 @@ public class SpinWaiter : BaseObject { * @see spin */ public new void notify() { - mutex.lock(); + //mutex.lock(); notified = true; cond.broadcast(); - mutex.unlock(); + //mutex.unlock(); } /**
I think I figured out what is happening. The new implementation of g_cond_wait_until (https://git.gnome.org/browse/glib/tree/glib/gthread-posix.c#n1411) releases the mutex for a VERY tight window of time. It will simply do a futex_wake syscall followed by re-acquiring the mutex right away. I think this window of time is not sufficient to allow for the notify() thread to ever wake up to acquire the mutex. g_mutex_lock() uses atomic increment - by the time the notify() thread gets woken up the wait() thread has already bumped up the atomic via g_mutex_lock() itself.
I've reviewed and applied your match from the mailing list. Although I still can't reproduce this problem w/ GTK+ 3.14, I can see how your change would solve a potential deadlock, so I'm applying it. Great work! Pushed to master, commit b22682
BTW, I've left this ticket's target marked for 0.8.2, reflecting the earlier fix. I'm contemplating a Geary 0.8.3 to be released soon, and your patch would be included in that.