Streaming NNTP bug (redux)

[River Tarnell]

Julien ÉLIE:
> If the write() function fails, "i" is negative and we substract "i"
> to cp->Out->left anyway.
> So if for instance i=-1, we end up in having cp->Out->left increased
> by one.  Which would, I believe, generate the bug you see:  an extra
> character is added after a complete response.  (So it appears in fact
> before a new response, just before 438 in this case.)

Hi,

When I restricted the number of outstanding CHECK/TAKETHIS commands to a 
fairly low number, I didn't see this problem.  It appeared after I 
removed the limit, so in some cases there could be >1000 commands in 
flight.  I imagine that in this case, write()ing the reply could easily 
return EAGAIN when it didn't with the lower limit.

So based on that reasoning, and code inspection of NCwritereply, I think 
your diagnosis and fix is correct.  I'm still trying to reproduce the 
problem on my own server; I'll try the fix there if I can.

PS: As it happens, I had exactly the opposite bug in my own 
implementation: my writev() implementation would drop the first 
character in the buffer when it didn't write the entire buffer.

Regards,
-- 
        -- river.                      | Free Usenet: http://news.rt.uk.eu.org/
Non-Reciprocal Laws of Expectations:   | PGP: 2B9CE6F2
    Negative expectations yield negative results.
    Positive expectations yield negative results.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4184 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/inn-workers/attachments/20120112/239c64b7/attachment.bin>