GNOME Bugzilla – Bug 350007
evolution busy-waits on GPG signing operations
Last modified: 2009-08-31 10:49:24 UTC
Please describe the problem: I use Gnupg together with seahorse-daemon acting as the gpg agent. I noticed that evolution eats 100% of the CPU while waiting for the agent to complete a signing operation. Steps to reproduce: 1. Send a signed mail 2. When the agent's confirmation window pops up... 3. ... run top and observe evolution's CPU usage Actual results: Expected results: Does this happen every time? Other information:
Ok, this is *really* annoying. If the gpg-agent process crashed then evolution will busy-wait *forever*.
+ Trace 86328
*** Bug 412979 has been marked as a duplicate of this bug. ***
And it causes laptops to heat up *fast*. Compiz also greys out evolution's windows as if they had crashed. Can't this thing run in a thread or something like that?
patches welcome :)
This version is no longer maintained, which means that it will not receive any further security or bug fix updates. The current stable GNOME and Evolution version is 2.26. Can you please check again whether this issue still happens in Evolution 2.24 or 2.26 and update this report by adding a comment and changing the "Version" field? Thanks a lot. Again thank you for reporting this bug and we are sorry it could not be fixed for the version you originally used here. Without feedback this report will be closed as INCOMPLETE in 6 weeks.
In my case it still happens with those new versions. As I'm not the reporter I can't reopen the bug though.
Jean-François, is gpg crashing for you in the background? For what reason?
No not the crash, just the cpu usage + evolution being hung until you answer that gpg prompt.
I'm sorry, what is "that gpg prompt"? Could you attach here a screenshot of the prompt, please? Because for me gpg doesn't ask anything and does everything smoothly. Of course, except of the password prompt for the private key access, but there I doesn't see any CPU usage.
Created attachment 140072 [details] screenscast of the GPG prompt eating the CPU With evolution 2.26 on a quadcore, you can clearly see one of the cores being pegged as soon as the passphrase prompt appears, and as long as it is not closed (whether you fill it or just cancel it).
Thanks for the update. My poor dual core doesn't suffer of this. But I remember seeing similar reports here or somewhere else, claiming the same as you (except I do not recall any machine details). Are you using a keyring or a password file? I'm using a password file, maybe that's the difference. Even I tried with keyring too, and I only get on the console: "Keyring key is unusable: no user or host name" but no CPU usage increase. I would like to ask you for one more thing. Could you attach (or even better paste) here a backtrace when you are asked for a password, to see what is evolution doing exactly, please? Just install debug info packages for evolution, evolution-data-server and run this command: $ gdb --batch --ex "t a a bt" -pid=PID &>bt.log where PID is a process ID of Evolution.
Created attachment 140106 [details] screenshot of the key setting Not sure what you mean by keyring vs password file. As you can see I just copied its ID from Seahorse into Evolution. I will try generating the requested debugging log.
Here is the backtrace. I ran evolution, and and when I had the passphrase prompt for signing, I cancelled it (because the thing prevents me from using any other windows on the system, including gnome-terminal, wtf!) and ran the gdb command. [Thread debugging using libthread_db enabled] [New Thread 0xb60c2770 (LWP 9175)] [New Thread 0xb30a5b90 (LWP 9221)] [New Thread 0xaf8ffb90 (LWP 9218)] [New Thread 0xb0af9b90 (LWP 9196)] [New Thread 0xb12fab90 (LWP 9195)] [New Thread 0xb22fcb90 (LWP 9194)] [New Thread 0xb1afbb90 (LWP 9192)] [New Thread 0xb4d00b90 (LWP 9186)] [New Thread 0xb5501b90 (LWP 9184)] 0xb7f80430 in __kernel_vsyscall ()
+ Trace 216825
FWIW, the reason why I used a quad core for this is that my atom-based netbook would not have been enough to screencast at the same time :)
(In reply to comment #13) > Here is the backtrace. I ran evolution, and and when I had the passphrase > prompt for signing, I cancelled it (because the thing prevents me from using > any other windows on the system, including gnome-terminal, wtf!) and ran the > gdb command. Oh, that's bad, the above trace is fine, only shows evolution in idle. The key trace is to see what it doesn't when the 4th core is busy. Strange it blocks the whole system. Please try to prepare your gdb command in the console before pressing "Send" in a composer, thus when you do that, the only two thins to do will be activating the terminal window and pressing enter. It'll do that with a bit of luck, only with slightly higher delay. I've no other idea what to do. :( keyring versus password file: evolution can be compiled with gnome-keyring support, and when you have it installed it stores its passwords there, thus you are asked to unlock the gnome-keyring on evolutions start. If it doesn't ask this, then you ae using the password file.
Ok, I need some clarifications... > The key trace is to see what it doesn't when the 4th core is busy. So you want the trace to happen "during" the hang/cpu spike? The problem is that this gdb command you gave me just runs instantly and exits, it doesn't "stay" there until I ctrl-C it or something like that... it doesn't have any time duration. Don't know exactly how to explain it. > Please try to prepare your gdb command in the console before > pressing "Send" in a composer, thus when you do that, the only two thins to do > will be activating the terminal window and pressing enter. Actually, that's what I had done, but even that did not work. I think I have an idea. I'll try doing that gdb command through SSH tonight, which should allow me to run it while the passphrase dialog is still shown. > evolution can be compiled with gnome-keyring > support, and when you have it installed it stores its passwords there, thus you > are asked to unlock the gnome-keyring on evolutions start. Aaah, ok, well yes, mine has gnome-keyring support. However, how is that related to GPG? The GPG keys are also inside that keyring? That would be surprising, especially that the prompt that I get is not the usual gnome-keyring prompts.
(In reply to comment #16) > Ok, I need some clarifications... > > > The key trace is to see what it doesn't when the 4th core is busy. > So you want the trace to happen "during" the hang/cpu spike? Yup, exactly in time the CPU is up. > The problem is that this gdb command you gave me just runs instantly and exits, > it doesn't "stay" there until I ctrl-C it or something like that... it doesn't > have any time duration. Don't know exactly how to explain it. yes, it's intentional, it should allow you to just run it and gather output. I wanted it as simple as possible. > > Please try to prepare your gdb command in the console before > > pressing "Send" in a composer, thus when you do that, the only two thins to do > > will be activating the terminal window and pressing enter. > > Actually, that's what I had done, but even that did not work. oh, bad :( > I think I have an > idea. I'll try doing that gdb command through SSH tonight, which should allow > me to run it while the passphrase dialog is still shown. please try. > > evolution can be compiled with gnome-keyring > > support, and when you have it installed it stores its passwords there, > > thus you are asked to unlock the gnome-keyring on evolutions start. > > Aaah, ok, well yes, mine has gnome-keyring support. However, how is that > related to GPG? The GPG keys are also inside that keyring? That would be > surprising, especially that the prompt that I get is not the usual > gnome-keyring prompts. Those are not stored there, but a call to retrieve it from gnome keyring is done anyway. Hmm, thinking of it now, maybe it doesn't call the keyring function, as some prerequisites fails, which is indicated on console.
Here is the backtrace (through SSH) during the passphrase prompt: [Thread debugging using libthread_db enabled] [New Thread 0xb60c8770 (LWP 13882)] [New Thread 0xb08f2b90 (LWP 13954)] [New Thread 0xafb42b90 (LWP 13952)] [New Thread 0xb0343b90 (LWP 13908)] [New Thread 0xb13cab90 (LWP 13905)] [New Thread 0xb23d7b90 (LWP 13904)] [New Thread 0xb1bd6b90 (LWP 13899)] [New Thread 0xb4d06b90 (LWP 13893)] [New Thread 0xb5507b90 (LWP 13891)] 0xb7f86430 in __kernel_vsyscall ()
+ Trace 216836
Thread 1 (Thread 0xb60c8770 (LWP 13882))
Hmm, interesting, my password prompt backtrace seems slightly different: ...
+ Trace 216866
Based on your line number, the camel-gpg-context.c:1062 is here: > 1059 do { > 1060 for (i=0;i<6;i++) > 1061 polls[i].revents = 0; > 1062 status = poll(polls, 6, 30*1000); > 1063 } while (status == -1 && errno == EINTR); thus it seems one of those file descriptors is constantly interrupted for some reason. Could you try to create a simple txt.txt file, with few letters and then run this command on a console, please: gpg --verbose --no-secmem-warning --no-greeting --sign --detach --armor -u "your_email_at_gpg_key" --output - txt.txt it's a very similar command which evolution invokes to sign a message. It only asks for a password for a private key and generates a signature for me. I wonder whether your gpg is asking for something more for you, which is making it interrupt during the polling above.
Tried that command (with the key ID as "-u", because the email address doesn't work), and I got the same "pinentry" dialog (with the same ultra-modal zealous-focus-grabbing thing), however there was no CPU usage at all (unlike when it's done in evolution). It just asked me or my passphrase, like Evolution. What's interesting is that no matter what I typed (and I know my passphrase!), it kept refusing it. If, instead, I right-clicked on the file and chose Sign, a very similar (but slightly different) dialog would appear (the non-zealous one, which used to appear with evo 2.24*), and entering the passphrase would work with it. * evo 2.24 still has this cpu usage bug nonetheless
Hrm, I'm getting more and more confused here. Together with loosing ideas how to chase this bug. Maybe I should ask before, but at least now: what are your exact versions for evolution, evolution-data-server, gnupg, gnome (or KDE?) and kernel, please?
evolution and evolution-data-server 2.26.1 gnupg 1.4.9-3 and gnupg2 2.0.9-3 seahorse 2.26.1 gnome 2.26.1 kernel 2.6.28-14.47 (though this has happened with any kernel I happened to be using for over 1-2 years, and maybe before that) Evolution is the only application that exhibits this behavior when signing/encrypting with GPG.
Great, I can reproduce it finally. Honestly, I didn't understand what you meant in comment #20 until I tried it. I found out that having enabled option use-agent in ~/.gnupg/gpg.conf causes this behaviour. I'm asked for the password for the first time through the agent, which is a very similar password dialog as evolution's, the only differences are more detailed information about the key and no checkbox for remembering the password for this session. The CPU is high. When I cancel this password prompt, then that evolution's native is shown, with no CPU usage at all. With use-agent commented it works fine. I'll try to investigate whether we can do anything with it.
Created attachment 140432 [details] [review] proposed eds patch for evolution-data-server; I use this patch, and yes, it is at that simple when one knows what to look for. Jean-François thanks for all your help and patience.
Looks fine as a stopgap. Would be nice to eventually defer entirely to seahorse for this stuff.
Created commit 3b95ade in eds master (2.29.1+) Created commit b2d5dc3 in eds gnome-2-28 (2.27.91+)
Hmhm, I'm bitten by this. Now evo won't use anymore my gpg agent, which it was before. It's really annoying, since I use gpg-agent especially for mail, but other stuff too. I really prefer storing my passphrase in gpg-agent than in evolution. Maybe there's a problem in evolution related to gpg-agent but disabling all support for everybody is a bit too much, imho. Could this be reconsidered?
(In reply to comment #27) > Could this be reconsidered? Are you using evolution with patch provided in comment#24 ? If you haven't applied the patch / fix, then please try after applying patche. If patch doesn't fix the problem for you, bug can be reopened.
I use pure evolution (and eds) 2.27.91, so yes it has the comment#24 patch, and that's the problem. I do want to use the gpg-agent in evolution, and this patch prevents me to do it. Could that be reconsidered? Cheers,
(In reply to comment #29) > Could that be reconsidered? Yes, it can. What kind of solution are you suggesting? Because having an option in evo, which is only used in eds, and only with gpg, seems strange to me, though I'm not sure, maybe we have there some similar already. Please note that evolution doesn't store the password for gpg on a disk, it's only in memory, and only in the active session when you allow it.
*** Bug 593043 has been marked as a duplicate of this bug. ***
(In reply to comment #30) > (In reply to comment #29) > > Could that be reconsidered? > > Yes, it can. What kind of solution are you suggesting? Because having an option > in evo, which is only used in eds, and only with gpg, seems strange to me, > though I'm not sure, maybe we have there some similar already. Well, the previous behavior worked fine, and this looks only like a workaround for the initial bug. I don't really know evolution internals, though, but still, removing any gpg-agent support altogether looks a bit too harsh. > Please note that evolution doesn't store the password for gpg on a disk, it's > only in memory, and only in the active session when you allow it. Yeah, but my point is that I use gpg-agent so I only store the decrypted key (or the passphrase) in one place (gpg-agent), and I use it from all apps needing it. I don't want it to be stored elsewhere. And for comfort reason, it's convenient not to have to retype the passphrase in evolution if I typed it in gpg-agent just before…
Created attachment 141923 [details] [review] proposed eds patch ][ for evolution-data-server; ok, this is much better solution then, even still kind of a workaround. I didn't find how to check whether the gpg is using the agent or not, it didn't show anything on its status_fd or others, thus this is trying to guess whether something goes with the agent. I wrote a little explanation to the code too.
Created commit c97799e in eds master (2.29.1+) Created commit d373548 in eds gnome-2-28 (2.27.92+)