Created attachment 332177 [details]
mail causing the issue

Is this one

Also, maybe as a consequence of that, if I try to reply to the mail, evolution gets stalled

Thanks for a bug report. It opens here in a tick of a second. The message is GPG signed, thus I guess the evolution is waiting for the GPG to respond. You can run evolution with:

   $ CAMEL_DEBUG=gpg evolution

to see the output from the GPG. It would be also good to install debuginfo packages for the evolution-data-server and evolution, then take a backtrace of the evolution while it is waiting. You can get the backtrace with command like this:
   $ gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt.txt
Please check the bt.txt for any private information, like passwords, email address, server addresses,... I usually search for "pass" at least (quotes for clarity only).

If it's really waiting for the GPG, then you might be facing some variant of the bug #741786, which is pretty old. The backtrace will show what it is doing.

With the CAMEL_DEBUG it's waiting with:
status: [GNUPG:] NEWSIG

But as soon as I run:
gdb --batch --ex "t a a bt" -pid=`pidof evolution` &>bt.txt

evolution window becomes completely stalled, is that normal? :/

Created attachment 332817 [details]
bt.txt

Finally it works ;)

This is the bt

And, once the mail is finally opened, the following two lines are shown by CAMEL_DEBUG:
status: [GNUPG:] ERRSIG 9709F90C3C96FFC8 1 10 01 1469364044 9
status: [GNUPG:] NO_PUBKEY 9709F90C3C96FFC8

Thanks for the update.

(In reply to Pacho Ramos from comment #4)
> evolution window becomes completely stalled, is that normal? :/

Yes, that's correct. As long as the gdb command runs the process doesn't update, because it's "paused" by the gdb.

The backtrace shows that the Thread 3 is waiting on gpg, thus it's due to it. I do not know what the gpg is waiting for, though. You can try to install debug package for the gnupg (and/or gnupg2) and capture similar backtrace from the gpg (or gpg2) process the evolution is waiting for.

I get this:
0x0000003df50dc430 in read () from /lib64/libc.so.6

+ Trace 236511

I have gnupg-2.0.30 (the same happens with 2.0.28)

What more information is needed? (I cannot switch this bug out of NEEDINFO status :( )

I'd need an information from a gnupg developer, but I do not know any being here, unfortunately.

I can try to ask our downstream maintainers of gnupg... maybe they know or, at least, they will be able to know who to contact about this :/

Any news about this? Should I report to gnupg people for asking them for help? (Well, I am still hitting this really often :S)

Thanks

I'm sorry, I lost track of this bug report. There is really nothing much to be done on the evolution-data-server side. I'm open for any advices from the gnupg folks, because as long as there is any gpg/gpg2 running at the time when the evolution is stuck, then it can be both evolution waiting for an output from the gpg/gpg2 incorrectly or the gpg/gpg2 not returning expected data, or even flushing its output buffers, thus the system can cache the pipe and cause the delay. I do not know how to verify that on the gpg/gpg2 side.

It looks like this is fixed with newer gnupg-2.1.x (now 2.1.15) over 2.0.x :/

I suppose it's a good news, isn't it?

Yeah, but I was waiting a bit to see with new mails if I was still suffering... it looks to work ;)

It is happening again :(
gnupg-2.1.15

Is there a way to know what concrete gnupg command is evolution trying to run? (to see if I can run it manually to at least see why it's failing or similar :/)

You do not need to reopen the bug report to ask questions.

If the gpg2 is still running then `ps ax | grep gpg` shows also the command line being invoked. Otherwise see:
https://git.gnome.org/browse/evolution-data-server/tree/src/camel/camel-gpg-context.c#n572
even it's a generic function which constructs the arguments based on the parameters.

This is the command:
gpg2 --verbose --no-secmem-warning --no-greeting --no-tty --batch --yes --status-fd=42 --verify /tmp/evolution-pgp.W3K7QY -


Before trying to ask gnupg guys... do you think is it ok? (or, at least, that was intended?) 

When running that manually I get it also hung:
$ LC_ALL=C gpg2 --verbose --no-secmem-warning --no-greeting --no-tty --batch --yes --status-fd=42 --verify /tmp/evolution-pgp.W3K7QY -
gpg: armor header: Version: GnuPG v2.0

If I drop the "-" at the end I get:
$ LC_ALL=C gpg2 --verbose --no-secmem-warning --no-greeting --no-tty --batch --yes --status-fd=42 --verify /tmp/evolution-pgp.W3K7QY 
gpg: armor header: Version: GnuPG v2.0
gpg: no signed data
gpg: can't hash datafile: No data

Is that normal?

Thanks

The --status-fd=42 says the gpg2 to write any "status" to file descriptor with number 42. Those are opened before the call is done. Hard to tell what it does when you run the same command line from a terminal. Either skip it, or use file number 1, to get it on stdout.

The --verify /tmp/evolution-pgp.W3K7QY expects an existing file /tmp/evolution-pgp.W3K7QY which contains a signed GPG data. It looks like the file doesn't exist or doesn't contain valid data.

I had a hard time to figure out what the '-' at the end exactly means, then I noticed the mention of it in the WARNINGS section of its man page:

> If you are going to verify detached signatures, make sure that the program
> knows about it; either give both filenames on the command line or use '-' to
> specify STDIN.

That sort of explains the change in the behaviour you see when removing it.

I re-read the backtraces above and what I see is that the evolution is waiting for a response from the gpg2 and the gpg2 is waiting for a response from a keyserver. Whether it's a local key server or a remote one I do not know.

I don't user any remote key server, how could I check my local key server is working? (at least, seahorse looks to open they keyring properly without dropping warnings or errors)

Thanks

Ah, regarding the /tmp files... I already checked them... they seem to exist and be readable (at least with "less")

they contain only PGP signatures, like:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.1
Comment: Robbat2 @ Orbis-Terrarum Networks - The text below is a digital signature. If it doesn't make any sense to you, ignore it.

iQJ8BAEBCgBmBQJYPgKxXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRDQjJEMjlCMjBCMkM5MUFDQzE2NDk2NkRB
RTcyMjg3ODM3QzU5RjVGAAoJEK5yKHg3xZ9fZPgQAJC4OmBHBkMai3sE2E7c8oDn
qHe9LChyydnpGtueRvIAhH78ZbnyJShj1iCeJrd2EElEcSqIDBiT6GT8kWCQRLia
odGTtyowXKjVAYFWr6KAI8DV3ceuJJ/EMCMTqx3f9xYXMSeK8g8w+FjGaxFXiQvN
BtYDO66rufIMg6mwwc4C3KNHbSudNEctlUho8LHsM/zJLEfA9t5EWIhAyi5W4nMF
/cSJGeBKs2VoLiz+tpWOYgTc3d+1l2UI48BX5sTGk/iC7iA641Z2i/7UF4Y9prrf
GoxuO2G9VFVhZrbIFP705AcYhw/oxcp/Jih2R5kHyJB62I3ZYSy8y1W9bRBiXBDv
ntW5v7v56tXkSUnz5XGsKICkEMvpxAs34M4zqPEjXqZ+r/GZKUJyU16Usejz2sxx
fCEU9lyFZayhicnZYEpEViLBhOep7TpeZMFg8lchIovVWLk4SSxjyy8T+Mje2/N7
HWX1NV1zaNPwud63sJDTBUKXq7zaWRM0ATm4uax6gl1INqiY7FADS9u8rfLUlHRr
PBBKnupO58z/s6qPQJjZ2VAsyAuO7Si8guU47sH1gcl40+2/0VOc2InXUeGQh3hQ
jVYmqSJMSkMpcK4ydSPOfCy6mVnvTdxLz3B67uo5irv17Smvux3eaJGgpFjd1Llb
sX30dxGp6Xef+x231pN7
=JARy
-----END PGP SIGNATURE-----

And, running gpg2 command with the --status-fd= set to 1, shows me this:
$ LC_ALL=C gpg2 --verbose --no-secmem-warning --no-greeting --no-tty --batch --yes --status-fd=1 --verify /tmp/evolution-pgp.U92WRY -
gpg: armor header: Version: GnuPG v2.1
gpg: armor header: Comment: Robbat2 @ Orbis-Terrarum Networks - The text below is a digital signature. If it doesn't make any sense to you, ignore it.

[It gets stalled at this point]

Ah, I have found and old setting in ~/.gnupg/gpg.conf... I had this:
keyserver hkp://subkeys.pgp.net
#keyserver mailto:pgp-public-keys@keys.nl.pgp.net
#keyserver ldap://keyserver.pgp.com

I commented also the first line and it seems to work now :D

Thanks a lot for your guidance and help! :)

(In reply to Pacho Ramos from comment #23)
> $ LC_ALL=C gpg2 --verbose --no-secmem-warning --no-greeting --no-tty --batch
> --yes --status-fd=1 --verify /tmp/evolution-pgp.U92WRY -
> gpg: armor header: Version: GnuPG v2.1
> gpg: armor header: Comment: Robbat2 @ Orbis-Terrarum Networks - The text
> below is a digital signature. If it doesn't make any sense to you, ignore it.
> 
> [It gets stalled at this point]

Right, it can be also waiting for the message content being passed to it through stdin.

(In reply to Pacho Ramos from comment #24)
> Ah, I have found and old setting in ~/.gnupg/gpg.conf... I had this:
> keyserver hkp://subkeys.pgp.net
> #keyserver mailto:pgp-public-keys@keys.nl.pgp.net
> #keyserver ldap://keyserver.pgp.com
> 
> I commented also the first line and it seems to work now :D

Aha. Maybe consider asking the gpg2 developers to set some shorter timeout limit for the key server connections.

Yeah, well, ideally it should be a bit more verbose about what it's doing (either gpg2 command trying to connect or evolution showing that it's waiting for gpg2)... but maybe it's too difficult to implement :/