Problems with inn on Fedora Core 4

Russ Allbery rra at stanford.edu
Sun Jan 29 01:04:47 UTC 2006


Paul Tomblin <ptomblin at xcski.com> writes:
> Quoting Russ Allbery (rra at stanford.edu):

>> I concur with your conclusion that it reads a few articles and then
>> dies, but from that I can't tell why it might be dying.  Can you get a
>> core dump, run gdb on it, and get a backtrace?

> gdb tells me that there are no symbols, so it's pretty useless.
> (gdb) where
> #0  0x003ce631 in _int_free () from /lib/tls/libc.so.6
> #1  0x003ceeba in free () from /lib/tls/libc.so.6
> #2  0x0805cfa7 in OVclose ()
> #3  0x0805116c in SMshutdown ()
> #4  0x0804c52d in ?? ()
> #5  0x00381e23 in __libc_start_main () from /lib/tls/libc.so.6
> #6  0x0804a7d1 in ?? ()

Huh.  That would imply that it's all done and is shutting down.  Does that
match what you see in the new history file?  Could it have possibly
finished?

If not, I wonder why it would be calling SMshutdown.

>> If you have valgrind handy, running makehistory under valgrind would
>> probably also be useful.

> ==16348== Conditional jump or move depends on uninitialised value(s)
> ==16348==    at 0x1B9036F8: free (vg_replace_malloc.c:152)
> ==16348==    by 0x805CFA6: (within /usr/lib/news/bin/makehistory)
> ==16348==    by 0x805116B: (within /usr/lib/news/bin/makehistory)
> ==16348==    by 0x804C52C: (within /usr/lib/news/bin/makehistory)
> ==16348==    by 0x381E22: __libc_start_main (in /lib/tls/libc-2.3.6.so)
> ==16348==    by 0x804A7D0: (within /usr/lib/news/bin/makehistory)
> makehistory: failed to malloc 2045106976 bytes at timecaf/caf.c line 246:
> Invalid argument
> makehistory: failed to malloc 2045106976 bytes at timecaf/caf.c line 246:
> Invalid argument
> ==16348==

Bleh.  That isn't too helpful either.  That conditional jump may be a
hint, or it may be noise.

I'm afraid I'm really not sure what's going on.  :/  Note that no on-disk
file formats changed between 2.3 and 2.4 in the INN code, so normally you
should be able to just copy all of the files over and shouldn't have to
run makehistory.

Oh, hm, I wonder if Red Hat could have possibly built 2.4 with large file
support and not 2.3.  timecaf does have a dependency on the size of an
off_t and such a change would have resulted in a change in on-disk file
format for timecaf buffers that could potentially confuse INN.

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



More information about the inn-bugs mailing list