inn-STABLE dumping core

Sven Paulus sven at karlsruhe.org
Tue Oct 5 19:01:41 UTC 1999


Hi,

I have a problem with a current snapshot (Oct 1st, 1999) of INN-STABLE:

innd dumps core because of a memcpy(0x0, ..., ...) in ARTparseheader():

(gdb) bt 
#0  0x400d37a3 in memcpy ()
#1  0x805b94d in ARTparseheader ( ....     at art.c:853
#2  0x805bb69 in ARTclean (Article=0x401ca86c, Data=0xbffff1c0) at art.c:973
[...]
(gdb) list
852         hp->Length = i;
853         (void)memcpy((POINTER)hp->Value, (POINTER)p, (SIZE_T)i);
854         hp->Value[i] = '\0';
(gdb) print hp
$22 = (ARTHEADER *) 0x80f8244
(gdb) print hp->Value
$23 = 0x0
(gdb) print hp->Name
$24 = 0x80e828e "Bytes"
gdb) print p
$25 = 0x414cf194 "659\r\nX-Originating-Host: 195.252.13 ...
(gdb) print i
$26 = 3

Ok, this is the Bytes-Header. The question is: Why is hp->Value == NULL?

In ARTsetup() we have:

    /* Allocate space in the header table. */
    for (hp = ARTheaders; hp < ENDOF(ARTheaders); hp++) {
        hp->Size = strlen(hp->Name);
        hp->Allocated = hp->Value == NULL && hp->Type != HTobs
                        && hp != &ARTheaders[_bytes];  
        if (hp->Allocated)
            hp->Value = NEW(char, MAXHEADERSIZE*2);
    }

The Space for hp->Value is allocated in ARTstore() ("HDR(_bytes) =
Data->Size;") which is also called in ARTpost(), but years after ARTclean()
(which itself calls ARTparseheader() containing the code above).

This is on a CNFS-only feeder machine (at this moment rejecting _all_
articles it gets, because the time is set to Dec 31 1999). 

Just skipping a Bytes-Header in ARTparseheader() would be the right
solution, I guess, but I still don't know, why this hasn't happened always
before when an article containing a Bytes-Header arrived.

--- art.c       Fri Oct  1 11:43:52 1999
+++ art.c.new   Fri Dec 31 07:59:13 1999
@@ -823,6 +823,10 @@
        return in;
     }

+    /* Skip the Bytes header */
+    if (hp == &ARTheaders[_bytes])
+        return in;
+
     if (hp->Type == HTsav) {
        *deltap = 0;
     }

Or is this wrong the wrong way to fix this problem?

Sven



More information about the inn-bugs mailing list