Am Mon, 2003-04-21 um 19.41 schrieb Jeffrey Stedfast:
> When can this condition ever happen?
Some more investigation:
The deadlock was introduced by the last update to camel-gpg-context.c
In gpg_verify you removed an additional check if the child has exited:
- while (!gpg_ctx_op_complete (gpg) && !gpg_ctx_op_exited (gpg)) {
+ while (!gpg_ctx_op_complete (gpg)) {
The change itself is correct, but the EOF detection in gpg_ctx_op_step
is broken (it doesn't detect an eof on the stdout pipe if no ostream
exists).
I noticed a strange behaviour before this. Every time when verifying a
signature the cpu usage went to 100% for half a second (system usage). I
suppose the EOF condition occured first causing evolution to go into
this endless loop, the signal that gpg died was emitted later, causing
the (now removed) backup check to exit the loop.
The strace to check what evolution was doing looked like this:
...
select(43, [38 40 42], NULL, NULL, {10, 0}) = 3 (in [38 40 42], left
{10, 0})
read(42, "", 4096) = 0
read(40, "", 4096) = 0
select(43, [38 40 42], NULL, NULL, {10, 0}) = 3 (in [38 40 42], left
{10, 0})
read(42, "", 4096) = 0
read(40, "", 4096) = 0
select(43, [38 40 42], NULL, NULL, {10, 0}) = 3 (in [38 40 42], left
{10, 0})
read(42, "", 4096) = 0
read(40, "", 4096) = 0
select(43, [38 40 42], NULL, NULL, {10, 0}) = 3 (in [38 40 42], left
{10, 0})
read(42, "", 4096) = 0
read(40, "", 4096) = 0
...
However sometimes the program manages to get out of the loop. It seems
the problem got worse with my latest kernel update but it's not the
kernel's fault.
> a few things:
> [...]
> 2) seen_eof1 is used differently in the case of gpg_verify(). Instead of
> being used as a eof marker, it is used to denote that we have gotten a
> trust metric for the data being verified. ie, we parsed a
> TRUST_[NEVER,MARGINAL,FULLY,ULTIMATE] status line from gpg's --status-fd
Hmm, ok. So seen_eof1 should become true before any eof condition arises?
I'll check what my gpg does here.
> apparently you have discovered a bug in gpg, although the
> camel-gpg-context code is a bit dodgy in this case as well.
The code should at least not call select over and over again when an eof
condition is signalled.
--
Christophe Saout <christophe saout de>
Attachment:
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil