Problems with inn on Fedora Core 4

Paul Tomblin ptomblin at xcski.com
Sun Jan 29 01:28:20 UTC 2006


Quoting Russ Allbery (rra at stanford.edu):
> Paul Tomblin <ptomblin at xcski.com> writes:
> > Quoting Russ Allbery (rra at stanford.edu):
> 
> > 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?

Well, there is the little problem that the new history file is empty.  And
that strace I send you shows it opening just a few of the 8250 timecaf
files.  I'm guessing it found some previous error, and then exited, and
while it was exiting it tried to free something that had already been
freed.

> >> 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 more worried about the huge mallocs.  Why is it mallocing 2Gb of
memory?

> 
> 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.

Hmmm.  Is there a way to see what the config options are in an rpm?

-- 
Paul Tomblin <ptomblin at xcski.com> http://xcski.com/blogs/pt/
Do you have a point, or are you saving it for a special occasion?
              -- David P. Murphy



More information about the inn-bugs mailing list