[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [NNTPCACHE] newshound SEGVs

Julian Assange wrote:
> > Entirely separately, in nntpcache.servers-dist, I saw some configs had a
> > very high Group timeout - 2 days. I would have thought this would greatly
> > confuse clients? Or do clients normally rely on xover anyway? Or does this
> > assume something like newshound is populating the cache in any case, so the
> > "group" article count will be pretty accurate really?
> The "group" command will update high water marks. But the examples you
> referrer to were aimed at modem links.

I was looking at:

# Example: leaf machine, fast link, one NNTP server, no local groups,

which has a group timeout of 2 days. Presumably that's a mistake then!

When the upstream news server has returned an error on connecting (400 Too
many cconnections), nntpcache has tended to respond with an error rather
than running out of cache, which is why I though a group timeout of 2 days
might not be a bad idea if clients don't object (but I thought they would).
So why is nntpcache giving an error then?

Looking at src/group.c:attachGroup() I see this bit:
        cf=attachServer (scfg);
        scfg->group = group_orig;
        if (!cf)
                emitrn (NNTP_SERVERTEMPDOWN);
                return FALSE;
        if (!attachGroupTalk(group, n, scfg, sendclient))
                if (!sendclient)
                        emitrn (NNTP_SERVERTEMPDOWN);
                return FALSE;

Perhaps instead of giving NNTP_SERVERTEMPDOWN, it should just never return
an error and drop through to the code below which should presumably(?) just
return the last cached values. Perhaps with a log just for the record.
Right? If so, I'll make a patch and try it.

Anyway, here's another newshound patch primarily to correct an off-by-one
error, revealed when receiving lines >1024 chars. In the main newshound
code though there's accidents waiting to happen due to ignoring
sock_gets()'s return code which I haven't fixed but someone should. Null
terminating the line on a disconnect may mitigate any problems though at


--- /home/jlarmour/nntpcache/socket.c	Wed Jul 29 16:14:31 1998
+++ ./socket.c	Mon Mar 25 19:59:00 2002
@@ -135,9 +135,11 @@
     bytes_read = read(sockfd, &last_read, 1);
     if (bytes_read <= 0) {
       /* The other side may have closed unexpectedly */
+      current_position[0] = 0;
       return -1; /* Is this effective on other platforms than linux? */
-    if ( (total_count < count) && (last_read != 10) && (last_read !=13) )
+    /* Leave room for trailing \0 */
+    if ( (total_count < (count-1)) && (last_read != 10) && (last_read
!=13) ) {
       current_position[0] = last_read;

Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

NNTPCache-users mailing list

[Index of Archives]     [Yosemite]     [Yosemite Campsites]     [Bugtraq]     [Linux]     [Trn]

Powered by Linux