GNOME Bugzilla – Bug 685640
Clicking on mail address in Iceweasel/Firefox, Evolution composer window opens, but Evolution hangs
Last modified: 2013-03-17 22:22:16 UTC
Clicking on a mail address in Iceweasel/Firefox, Evolution 3.4.3-1 in GNOME fallback from Debian Sid/unstable opens a composer window, but Evolution hangs then, that means I can just see the title bar and all the window content is gray. $ ps aux | grep evol joey 2821 0.0 0.4 419120 15796 ? Sl 19:59 0:00 /usr/lib/evolution/3.4/evolution-alarm-notify joey 2869 0.0 0.3 331040 11728 ? Sl 19:59 0:00 /usr/lib/evolution/evolution-calendar-factory joey 2895 0.0 0.2 295088 9784 ? Sl 19:59 0:00 /usr/lib/evolution/evolution-addressbook-factory joey 4371 105 4.0 873972 155848 ? Rl 21:56 30:50 evolution --component=mail mailto:info@example.net joey 4652 0.0 0.0 11760 872 pts/3 S+ 22:25 0:00 grep evol Attaching with GDB to process 4371 produces the following backtrace.
+ Trace 230984
Thread 3 (Thread 0x7f66559a1700 (LWP 4377))
Thread 1 (Thread 0x7f666af32980 (LWP 4371))
Inferior 1 [process 4371] will be detached. Quit anyway? (y or n) Detaching from program: /usr/bin/evolution, process 4371 After that the only way to get it closed, was to run `kill -9 4371` which killed all Evolution processes. Could you please take a look? I guess it could also be a GTK problem.
Radeon video driver thread looks stuck:
+ Trace 230990
Thread 5 (Thread 0x7f6656d4d700 (LWP 4375))
(In reply to comment #1) > Radeon video driver thread looks stuck: […] Thanks for the quick reply! I contacted the developers sending a message to dri-devel [1]. [1] http://lists.freedesktop.org/archives/dri-devel/2012-October/028648.html
(In reply to comment #1) > Radeon video driver thread looks stuck: That isn't necessarily a problem: It's a worker thread, this is where it's waiting for work to come in from a GLX context thread.
Thanks for your input. Could this be GTK+ problem?
Here is the version and dependency information. Package: libgtk-3-0 Version: 3.4.2-4 -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libgtk-3-0 depends on: ii libatk1.0-0 2.4.0-2 ii libc6 2.13-35 ii libcairo-gobject2 1.12.2-2 ii libcairo2 1.12.2-2 ii libcolord1 0.1.21-4 ii libcomerr2 1.42.5-1 ii libcups2 1.5.3-2.3 ii libfontconfig1 2.9.0-7 ii libfreetype6 2.4.9-1 ii libgcrypt11 1.5.0-3 ii libgdk-pixbuf2.0-0 2.26.1-1 ii libglib2.0-0 2.33.12+really2.32.4-2 ii libgnutls26 2.12.20-1 ii libgssapi-krb5-2 1.10.1+dfsg-2 ii libgtk-3-common 3.4.2-4 ii libk5crypto3 1.10.1+dfsg-2 ii libkrb5-3 1.10.1+dfsg-2 ii libpango1.0-0 1.30.0-1 ii libx11-6 2:1.5.0-1 ii libxcomposite1 1:0.4.3-2 ii libxcursor1 1:1.1.13-1 ii libxdamage1 1:1.1.3-2 ii libxext6 2:1.3.1-2 ii libxfixes3 1:5.0-4 ii libxi6 2:1.6.1-1 ii libxinerama1 2:1.1.2-1 ii libxrandr2 2:1.3.2-2 ii multiarch-support 2.13-35 ii shared-mime-info 1.0-1+b1 ii zlib1g 1:1.2.7.dfsg-13 Versions of packages libgtk-3-0 recommends: ii hicolor-icon-theme 0.12-1 ii libgtk-3-bin 3.4.2-4 Versions of packages libgtk-3-0 suggests: ii gvfs 1.12.3-1+b1 ii librsvg2-common 2.36.1-1 -- no debconf information
Hi, yap I can confirm this with Evolution 3.4.4 It does not happen every time, tough. I click on mailto: links in the Opera webbrowser. I am on Feodra 17. Also attaching my backtrace and strace log. I do not see the Radeon driver thread stuck. I hope all threads were printed by gdb. [nazgul@rivendell ~]$ yum info evolution* Geladene Plugins: auto-update-debuginfo, langpacks, presto, refresh-packagekit Installierte Pakete Name : evolution Architektur : x86_64 Version : 3.4.4 Ausgabe : 2.fc17 Größe : 44 M Repo : installed
hmm it does not deadlock/hang but stays in a loop with 100% CPU load, see Thread #3 Same symptoms as described in the first post.
Created attachment 229492 [details] gdb debug
Created attachment 229494 [details] strace call log
FWIW, if you can set the environment variable RADEON_THREAD=0 for the evolution process, that should prevent the Radeon driver from spawning a helper thread.
A common part for the backtraces is that both has a dconf thread in an update state due to change in /org/gnome/desktop/interface/ path. The first backtrace also reads from there in gtkhtml, but it's because it reacts on the change, I believe. The question is why dconf thinks the path (or any key under it) changes. Is the composer broken in the same way if it's opened in evolution itself, like with Ctrl+Shift+M? And what if you run on console evolution like this: $ evolution mailto:a@b.c will the composer be OK? I see high CPU usage when I run the above command when no other evolution is running, though it's pretty quick and settles shortly.
Luckily I have not hit that problem again. But also did not try too hard to reproduce this. For those of you who are able to reproduce this, maybe running `sudo perf record -a` gives any hints, where it is stuck.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!