still happening, any detail that could be useful for you?

+ Trace 67581

<dholbach> I think it receiving new mails, while I jumped to another folder and it wanted to display a message
<dholbach> i don't think it was a big mail, but it might have been caused by a gpg key? does that make sense?

bug #331172 seems to be the same issue

reassigning it to the mailer team

still happening with 2.14.1

FYI...

I was having these problems as well, then googled and checked bugzilla and found someone mentioned it could be gpg.  I remembered during one hang, the status said 'Verifying signature...'.

So I checked ~/.gnupg/options and removed 'auto-key-retrieve' from my 'keyserver-options' setting.  It has now been a couple of weeks without a crash in evolution.

Evolution 2.6.1 from up to date Ubuntu Dapper (gnome 2.14.2).

I had another hang today, with the following backtrace.  I figured how to trigger the crash here however.  Find a folder with many messages in it (mine has 590).  Use a filter to display only some of them (mine shows 33 messages of the 590).  Choose a message within these filtered messages that has a gpg signature to be validated (key does not have to be in your keyring).  Then click 'Clear' to clear the filter and then click another folder quickly (while it is still indexing the folder).  It will hang while saying 'Verifying signature'.

I can only assume that this will work on any folder meeting the above, but the messages I am using are a folder full of debian security mailing list entries with the filter as 'kernel' and choosing a message from 'Moritz Muehlenhoff'.

Strace will follow.


0xffffe410 in __kernel_vsyscall ()
(gdb) bt

+ Trace 69864

Created attachment 70025 [details]
part one of strace from crash

Created attachment 70026 [details]
part 2 of strace from crash

To view the strace, do:
$ gzip -d ./evo.strace_pt1
$ gzip -d ./evo.strace_pt2
$ cp ./evo.strace_pt1 ./evo.strace
$ cat evo.strace_pt2 >> ./evo.strace

I said in uploading the strace files that this was a 'crash', but it is a UI hang.

I played with this some more, and found that it is only some messages with gpg signatures.  I will attach a message from the debian security list that will hang evolution.

Steps to reproduce the hang:
1. Save the attached as hang_trigger_email and uncompress it with gzip

2. Open evolution and create a folder called 'Crasher'

3. Import the hang_trigger_email into evolution (via File/Import) into the Crasher folder

4. Navigate to the Crasher folder (hang_trigger_email will be the only email in the folder)

5. enter a search filter of 'kernel' and click 'Find now'

6. select the message

7. press 'Clear' to clear the search filter

8. UI hangs

GPG signed emails from some people work fine, but signed emails from other people do not.

Created attachment 70029 [details]
email to trigger a UI hang

is it maybe gpg hanging trying to fetch the key from a keyserver?

can you try disabling that gpg feature in your ~/.gnupg/gpg.conf file?

In a previous post I mentioned that auto-key-retrieve is disabled.  Still happens.

$ cat ~/.gnupg/options | grep keyserver
# GnuPG can send and receive keys to and from a keyserver.  These
# Example HKP keyserver:
#      x-hkp://keyserver.cryptnet.net
# Example email keyserver:
# Example LDAP keyserver:
#      ldap://keyserver.pgp.com
#      x-hkp://keyserver.example.net:22742
#      x-broken-hkp://keyserver.example.net
# Most users just set the name and type of their preferred keyserver.
#keyserver x-hkp://keyserver.cryptnet.net
#keyserver mailto:pgp-public-keys@keys.nl.pgp.net
#keyserver ldap://keyserver.pgp.com
# Options for keyserver functions
#                    on the keyserver (not all keyservers support this).
#                   on the keyserver.
#                  keyserver.  Some platforms (Win32 for one) always
# honor-http-proxy = if the keyserver uses http, honor the http_proxy
#                     keyserver when verifying signatures or when importing
#keyserver wwwkeys.pgp.net
#keyserver x-hkp://keyserver.cryptnet.net
#keyserver-options auto-key-retrieve include-disabled include-revoked
#keyserver-options include-disabled include-revoked

Here is a backtrace with debugging symbols:

(gdb) bt

+ Trace 69866

I didn't have a such hang for some time, it seems to be fixed with GNOME 2.15.n 

does it work with the procedure I detailed above and the attached email?

I've not tried with that mail but it looks like a standard gpg signed mail, I used to have the issue pretty often and that was the case for other Ubuntu users too, nobody seemed to had it in weeks now with GNOME 2.15.n so I would say it's fixed

I tried with that email in an Ubuntu Edgy live cd and it didn't hang.  So it appears to be fixed in 2.15.x.

Is there any chance for the change to be committed to 2.14?  I just moved a lot of people to Ubuntu Dapper because of its 3 years support and this bug, while not a showstopper, is definitely annoying.  I am sure other distributions are in the same situation as well.

if you figure what commit fix it and it's simple enough to be backport I would be happy to patch the package for that. figuring what change fixes that issue when you have the bug every now and then is not trivial :/

Absolutely-- the occasional hang is very hard to fix.  However, I provided an email which will trigger it consistently on Dapper.  I also provided backtraces with debugging symbols, straces and I tried to look through the code, but the evolution codebase is rather daunting for someone new to it.  I'd tried running evolution through ddd, but I don't have the experience debugging evolution to get very far (I'm a sysadmin with some programming skills, but not a gnome hacker).  I'll happily test patches though.

note that I'm not an evolution hacker but just packaging it for Ubuntu so I don't know the code neither, the comment was rather for upstream to know if they could point to the right direction to get a patch to backport ;)

Is it still valid, can you please try in current stable 2.22.3, thanks in advance.

there has been no recent activity on the bug and I didn't get the issue in a while, let's close the bug