[pkg-gnupg-maint] Bug#841143: Bug#841143: False assumptions about nPth (was: Bug#841143: Suspected race in gpg1 to gpg2 conversion or agent startup)

[Ian Jackson]

Daniel Kahn Gillmor writes ("Re: [pkg-gnupg-maint] Bug#841143: False assumptions about nPth	(was:	Bug#841143: Suspected race in gpg1 to gpg2 conversion	or agent startup)"):
> You're just talking about adding this one test, right?

That's my understanding.

> It seems to me like this shouldn't be necessary, since i'd have thought
> the child channel (chan_9 in your example) receiving eof would make the
> main thread wake back up.

AIUI this is supposed to happen, indeed.  So the timer tick is hiding
the race, by having gpg-agent wake up occasionally anyway and become
unstuck.

> can you explain why that wouldn't be the case?  is there some way to
> cause the main thread to trigger a loop when the child channel closes?

There's interrupt_main_thread_loop.  But it is not called.  I think it
should be called when active_connections becomes zero.

That's what my patch 4/4 does, and that patch fixes most of the
problem for me.

There is a remaining race with much lower probability.  I think It
happens when an incoming connection arrives just as gpg-agent is
finally deciding to actually exit.  The symptoms are that some gpg
invocation complains about getting EOF from the agent.

Thanks,
Ian.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.