| Summary: | Deadlock when viewing signed messages | ||
|---|---|---|---|
| Product: | [Unmaintained] kmail | Reporter: | David Southwell <david> |
| Component: | encryption | Assignee: | kdepim bugs <kdepim-bugs> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | crash | CC: | lemma, lofi, matt, nick.allen |
| Priority: | NOR | Keywords: | triaged |
| Version: | 1.9.6 | ||
| Target Milestone: | --- | ||
| Platform: | FreeBSD Ports | ||
| OS: | FreeBSD | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Mails that do & do not cause hang | ||
|
Description
David Southwell
2007-06-29 15:59:09 UTC
Please do NOT paste such huge outputs directly in bugzilla. Am I correct in my assumption that KMail doesn't crash, but hang (without using CPU) and that this only occurs when viewing certain mails which have a signature? On Saturday 30 June 2007 05:48:31 Thomas McGuire wrote: [bugs.kde.org quoted mail] It mostly hangs but sometimes crashes. When it crashes (very rarely) it brings kde down with it. Unfortunately I have not been able to catch that on a debug. I am assuming solving the hang will also solve the crash <chuckles -- at huge assumption>. Your comment about signatures means you are far more observant than I am. I have the impression that there are emails without signatures on which it hangs BUT please do not rely on that as it is only an impression. Thanks for getting back to me. Sorry about the length of the output.. I received a recomendation to post the whole output because I was told it would be helpful to do so-- so I went ahead. apologies david The GDB backtrace was useful (you can see that KMail checks the signature during the deadlock), but the output from KMail itself wasn't useful and just makes the bug report harder to read. Such output should be attached in the future. But that is not a big problem anyway. The deadlock happens because KMail starts gnupg as an external process and then waits for it to do something. For some reason, gnupg never finishes, which is why KMail deadlocks. In the duplicate report bug 147395, the reason for this is that gnupg tries to contact a server which can't be reached. *** Bug 147395 has been marked as a duplicate of this bug. *** On Saturday 30 June 2007 07:12:09 Thomas McGuire wrote: [bugs.kde.org quoted mail] That makes sense.. Is there any understanding as to whether the bug is due to kmail not calling the external process properly OR is there a bug in gnupg? From what you are saying it seems that kmail may be calling gnupg and failing if either a. It does not get a reply it expects (possibly in my case an unexpected reply) OR b. receives no reply at all (in the case of 147395 an unreachable server). In combination does this not increase the likeliehood that there is a failure in kmail's routine for handling calls to gnupg? FWIW gnupg is used quite a lot on my system without any apparent problems. I do not know whether it will help but running: # pkg_info |grep gnupg gnupg-1.4.7_1 The GNU Privacy Guard gnupg-2.0.4 The GNU Privacy Guard shows that two versions of gnupg are installed on this system. david > Is there any understanding as to whether the bug is due to kmail not > calling the external process properly OR is there a bug in gnupg? From what > you are saying it seems that kmail may be calling gnupg and failing if > either a. It does not get a reply it expects (possibly in my case an > unexpected reply) OR > b. receives no reply at all (in the case of 147395 an unreachable server). > > In combination does this not increase the likeliehood that there is a > failure in kmail's routine for handling calls to gnupg? I don't know where the problem lies. It was discussed to make the calls to the gpg stuff asynchronous, but I don't now how far this is progressed. That would at least solve those deadlocks. Umph I would be willing to run any tests on my system to help identify where the problem lies. The failure is reliably reproducable <wry smile. as well as a great inconvenience. What surprises me is that the bug is not more frequently reported. Could this bug be specific to a particular hardware/software combination? Here is the output of # uname -a FreeBSD dns1.vizion2000.net 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Sun May 7 04:15:57 UTC 2006 root@bloom.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP amd64 I can also supply a list of installed ports if that would be useful. david I don't think the hangs and the crashes are related - gnupg triggered temporary hangs on automatic key retrieving attempts are known to me, but kmail should recover from them once gnupg's attempt times out (which shouldn't take longer than a minute at most). On the other hand, I don't use kmail's filter engine, so it could be there's a deadlock condition with gnupg hidden in there somewhere. David, perhaps you can try turning off auto-key-retrieve in gnupg if you have turned it on (comment out keyserver-options auto-key-retrieve in ~/.gnupg/gpg.conf) or just specify no keyserver for gnupg at all and see if that changes things. Created attachment 21070 [details]
Mails that do & do not cause hang
See attachment
I tried amending .gnupg as suggested but that made no difference david Interestingly hangs only occur when mail is unread. Once marked read hangs for the same mail cease. Is this or is this not weird??? *** Bug 149003 has been marked as a duplicate of this bug. *** You mention in #149003 that it's only reported on FreeBSD -- I had the problem under Linux (#147395) I do not agree that 149003 is a duplicate. The symptoms are different. This bug (147358)produced a hang in all circumstances. 149003 produces a crash (a total kde crash and system crash necessitating power off to reboot the system when the kmail window is maximized. 147358 did not exhibit that extreme behaviour. 149003 produces a hang when the window is not maximized. The differentiate behaviour is a clear symptom of a different bug. It seems to the only benefit of marking 149003 as resolved and making it a duplicate of 147358 is to artificially inflate the number of resolved bugs whilst leaving both in a state of limbo. Franky I am a bit disappointed after making a considerable amont of effort to clearly report the bug and produce detailed gdb reports for both that there appears to be no feed back indicating that the bugs are being treated seriously. On the other hand a rather confusing comment was left by Bram on Bug 149003 which necessitated the following response: ""Comments such as "Looks like some things go horribly wrong on FreeBSD." are not helpful nor do they inspire condfidence. Are you saying this bug is something to do with the freebsd environement. If so why is this the only application out of 800+ ports (including 26 kde applications and the kde meta-port) that crashes on this system? Or are you saying this is a bug in kdepim bug in kdepim that only shows up in a Freebsd environment??? What exactly are you saying? Please be a little clearer. Whatever this needs resolving."" IMHO a little more respect for those who take the trouble to provide detailed bug reports and some indication of likely response times would go down well. Thanks >You mention in #149003 that it's only reported on FreeBSD -- I had the problem under Linux (#147395)
Yes, because your hang seems to be caused by a remote server which can't be reached and FreeBSD hangs because of some other, unknown reason.
The end result is however the same: KMail waits for the GPG process to finish, which never happens. Therefore, KMail hangs as well.
Having a quick look at the code I see that KMail should indeed be calling gnupg asynchroneously now. Did this problem get solved by a recent release? No feedback for 4 monthes. Closing this report. |