INN 2.2.2 blew up in NGfind (ng.c:278)

[Russ Allbery]

Bert Hyman <bert at rsvl.unisys.com> writes:

> My INND 2.2.2, running on FreeBSD 3.4 on a P-200, blew up yesterday
> afternoon after running for over a month without a stop (the system has
> been in service for about 3 months).

> GDB says:

>> Program terminated with signal 11, Segmentation fault.
>> ...
>> #0  0x805f7ba in NGfind (Name=0x81ad000 "alt.conspiracy.spy") at ng.c:278 
>> 278             if (c == ngp[0]->Name[0] && EQ(Name,ngp[0]->Name))
>> (gdb) bt
>> #0  0x805f7ba in NGfind (Name=0x81ad000 "alt.conspiracy.spy") at ng.c:278 
>> #1  0x8051adf in ARTpost (cp=0x8096208) at art.c:2384
>> #2  0x805b68e in NCpostit (cp=0x8096208) at nc.c:197
>> #3  0x805ca4d in NCproc (cp=0x8096208) at nc.c:937
>> #4  0x805d14e in NCreader (cp=0x8096208) at nc.c:1164
>> #5  0x8058015 in CHANreadloop () at chan.c:946
>> #6  0x805b14a in main (ac=8, av=0xbfbfdd48) at innd.c:944

> It appears that ngp[0] is zero at the point of failure.

This is a corrupted active file hash table in memory.  I just went over
the code again and I don't see any simple way for that to happen
(basically, to get the results that you saw, Used for that hash bucket was
greater than 0 but there wasn't actually anything in the bucket).  Memory
corruption would be one possibility, of course.  I don't have any
particularly good suggestions on how to track this down, though.  :/

> Looking back in DejaNews, it looks like this identical failure has been
> reported sporadically for several years, back as far as INN 1.5.1!

That's because it's basically "generic failure in active file hash table."

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>