Re: [Evolution-hackers] Deadlock in camel-gpg-context.c

[Jeffrey Stedfast <fejj ximian com>]

On Mon, 2003-04-21 at 15:19, Christophe Saout wrote:
> 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).

the logic was that we were *supposed* to get a TRUST status message from
gpg's --status-fd, but it seems we never did.

> 
> 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?

yes.

> 
> 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.

which eof signal? anyways, my patch should correct the problem.

Jeff

-- 
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fejj ximian com  - www.ximian.com