innfeed: cxnsleep can't write command: Bad address [PATCH]
"Miquel van Smoorenburg"
list-inn-workers at news.cistron.nl
Mon Jun 6 16:51:16 UTC 2005
In article <87ll5oqfd6.fsf at windlord.stanford.edu>,
Russ Allbery <rra at stanford.edu> wrote:
>"Miquel van Smoorenburg" <list-inn-workers at news.cistron.nl> writes:
>> I've seen this message regularly in my logs:
>> May 2 01:40:47 quantum innfeed: transit.news.xs4all.nl:6
>cxnsleep can't write command: Bad address
>> May 2 01:40:47 quantum innfeed: transit.news.xs4all.nl:6 final
>seconds 26 offered 249 accepted 59 refused 181 rejected 6 accsize
>21955221 rejsize 2292445
>> .. but hadn't payed much attention to it. Now that I am using
>> innd/innfeed to feed much more diablo boxes a full feed, I'm
>> seeing it more and more.
>> It turns out that Diablo can return an "article rejected" status
>> before the entire article has been transfered. But by then,
>> hostArticleRejected has called delArticle and SMfreearticle()
>> or munmap() has been called, and the nntpBuffers point to
>> data no longer there. Which means that writev() will EFAULT.
>> The correct solution is to put arthandle/mMapping in a seperate
>> struct and refcount it, only releasing it when the last buffer
>> that references it is deleted.
>I'm not at all sure that I like this. It adds another layer of reference
>counting to the layer that we already have, and as near as I can tell, is
>doing so because the existing reference counting doesn't work properly.
>Shouldn't we instead fix the reference counting on articles so that
>delArticle won't free the allocated data while it's still referenced
>It seems like the truly correct thing to do here is to teach
>hostArticleRejected how to dig the article out of the NNTP buffers for
>that host before deleting it.
Well the buffer really is just a pointer to mmap'ed memory,
which hostArticleRejected is going to unmap. I don't understand
what you mean with "dig the article out of the NNTP buffers".
>Failing that, the NNTP buffers should also
>hold a reference to the article that they drop when the article has been
>written out completely.
>Do you agree? Am I missing something?
That was how I originally tried to fix it. But I didn't like
Articles holding references to Buffers that again hold references
to Articles. delArticle will call delBuffer which will, ehrm,
call delArticle again .. besides how do you get a reference to
the article from within buffer.c.
So I took a different approach.
But, if you keep the bufferSetDeletedCbk infrastructure in place that
I added, I guess you could do it without MapInfo. The callback
would just do a (if article->refCount > 0) delArticle(article),
static void delArticleFromBuffer(void *a)
Article article = a;
if article->refCount > 0)
static bool fillContents (Article article)
article->contents = newBufferByCharP(mMapping,
article->refCount++; /* one more for the buffer */
bufferSetDeletedCbk(article->contents, delArticleFromBuffer, article);
What do you think ?
The From: and Reply-To: addresses are internal news2mail gateway addresses.
Reply to the list or to "Miquel van Smoorenburg" <miquels at cistron.nl>
More information about the inn-workers