nnrpd/expireover/whatever bug (not sure where) preview

Bernd Jendrissek berndj at prism.co.za
Fri Oct 18 11:51:20 UTC 2002

Hash: SHA1

[I'd greatly appreciate Cc'ed replies.]

A few days ago expireover started segfaulting on me again.

INN 2.3.3
ovmethod buffindexed (and I don't want to change that, I want to *fix* this.)
very little traffic, ~20 private unused froups + ~20 "real" ones.

So then I rebuild overview and history.  No problems apparent there... yet.
So when I wanted to goof off a little in comp.dcom.cabling, rtin got halfway
and then stopped (at the part where it says foo bar mumble... 59%).  Back
to my favourite newsreader (telnet) I got closer to the heart of the matter.

For example I'd have:
C: group comp.dcom.cabling
S: 211 700 2422 3574 comp.dcom.cabling
C: xover 2422-3574
S: 400 pages of overview, BUT...

The interesting thing is that INN sends back *some* overview, but then just
stops.  The last line is overview, not the ".\r\n" terminator.  And yet
nnrpd (or is it innd?) accepts other commands, "quit" at least.

So yesterday I got fed up and attached gdb to nnrpd.  Lo and behold, it
seems like somebody's trying to write almost a gigabyte in one SendIOv()
call.  Oops.

Unfortunately I can't track it down now; it's all mysteriously working
again.  (This seems to happen - it just "settles down" after a few days and
just works again.  I suppose expireover will just stop segfaulting as well.)

But I did intrument article.c in a spot where the wheels seemed to come off.
SendIOv is probably a victim here, not the cause of the bug.  I'll look a
bit upstream later today, but maybe one of the INN gurus are more able here.

Here's the patch with its result following:

diff -ur inn-2.3.3/nnrpd/article.c inn-2.3.3-bernd/nnrpd/article.c
- --- inn-2.3.3/nnrpd/article.c   Thu May  3 22:27:32 2001
+++ inn-2.3.3-bernd/nnrpd/article.c     Thu Oct 17 23:22:02 2002
@@ -132,6 +132,7 @@
     if (MaxBytesPerSecond != 0)
        return PushIOvRateLimited();
+    syslog(L_TRACE, "iov[%d]", queued_iov);
     if (writev(STDOUT_FILENO, iov, queued_iov) <= 0) {
       queued_iov = 0;
       return FALSE;
@@ -144,8 +145,16 @@
 BOOL SendIOv(char *p, int len) {
     char                *q;
+    if (len > IOV_MAX) {
+      /* Er, no, IOV_MAX is how many iov *elements* there are. */
+      syslog(L_TRACE, "SendIOv: whoops, sending too much (%d/%d) in an iov",
+            len, IOV_MAX);
+    }
     if (queued_iov) {
        q = (char *)iov[queued_iov - 1].iov_base + iov[queued_iov - 1].iov_len;
+       syslog(L_TRACE, "SendIOv: iov[%d].%d < %d total %d",
+              queued_iov - 1, iov[queued_iov - 1].iov_len, len,
+              iov[queued_iov - 1].iov_len + len);
        if (p == q) {
            iov[queued_iov - 1].iov_len += len;
            return TRUE;

Oct 17 23:18:20 penguin nnrpd[12701]: SendIOv: iov[6].720 < 376 total 1096
Oct 17 23:18:20 penguin nnrpd[12701]: SendIOv: iov[6].1096 < 324 total 1420
Oct 17 23:18:20 penguin nnrpd[12701]: SendIOv: whoops, sending too much (9096543
23/1024) in an iov
Oct 17 23:18:20 penguin nnrpd[12701]: SendIOv: iov[6].1420 < 909654323 total 909
Oct 17 23:18:20 penguin nnrpd[12701]: SendIOv: iov[6].909655743 < 321 total 9096
Oct 17 23:18:20 penguin nnrpd[12701]: SendIOv: iov[7].321 < 302 total 623
Oct 17 23:18:20 penguin nnrpd[12701]: SendIOv: iov[7].623 < 310 total 933

- -- 
berndfoobar at users.sourceforge.net is probably better to bookmark than any
employer-specific email address I may have appearing in the headers.
  Vanity page: http://www.tsct.co.za/~berndj/  Ugh, seems to be down.
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org


More information about the inn-bugs mailing list