nnrpd/expireover/whatever bug (not sure where) preview
Bernd Jendrissek
berndj at prism.co.za
Fri Oct 18 11:51:20 UTC 2002
-----BEGIN PGP SIGNED MESSAGE-----
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 @@
#else
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
655743
Oct 17 23:18:20 penguin nnrpd[12701]: SendIOv: iov[6].909655743 < 321 total 9096
56064
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9r/WU/FmLrNfLpjMRAi/TAJ4ylqREB1gsDlaAP87E6/MZZtlM3ACffIyJ
8+rwGN2J3t0HvqpNZJhhRog=
=oiXv
-----END PGP SIGNATURE-----
More information about the inn-bugs
mailing list