Re: Race condition in public-inbox-nntpd?

[Eric Wong <e@80x24.org>]

Jonathan Corbet <corbet@lwn.net> wrote:
> So for a little while, I've been seeing occasional NNTP weirdness,
> associated with log lines like:
> 
>   Oct 13 18:01:06 archive.lwn.net public-inbox-nntpd[12352]: error from:
>   XOVER 196731-196731 (BUG: nested long response at /usr/local/share/perl5/PublicInbox/NNTP.pm line 588.
> 
> Such complaints tend to be immediately followed by significant
> disgruntlement on the client side.

Do you have any logs of client commands which hit this?

public-inbox-nntpd should log commands + timings to stdout.

> I use gnus to read the various NNTP feeds, and I mark articles (with "u")
> when I want to keep them around; I typically have quite a few of them
> marked at any given time in a group like linux-kernel.  When I open the
> group in gnus, it will do an XOVER on each of those marked articles,
> generating dozens of single-article XOVERs in quick succession.  It's
> always the single-article ones that fail; the big XOVER for all of the new
> stuff at the end works just fine.
> 
> Another user has complained that things fail with Thunderbird, again with
> the same symptoms on the server side.

No idea how to use either gnus or tbird, here; so a command
sequence which can be fed into nc or socat would be helpful in
reproducing the problem.

Any relation to group size in reproducing this?

> I have "fixed" the problem with this little patch:

<snip>

> That makes things work, but it is clearly papering over the real
> problem.

Agreed.

> I've spent a fair while staring at the code.  As far as I can tell, the
> logic there should be sufficient to prevent this from happening; it's not
> supposed to be reading while a long response is in the works.  But somehow
> it happens.

I stared at it some, too; but I'm not seeing it right now, either;
but it's been a tiring few weeks for me so I'm not at my sharpest.

Thanks for bringing this to everyones' attention.