Latest core dump ... newest CVS ...

[Alex Kiernan]

Alex Kiernan <alexk at demon.net> writes:

> Russ Allbery <rra at stanford.edu> writes:
> 
> > The Hermit Hacker <scrappy at hub.org> writes:
> > 
> > > definitely reproducable .. not 15min later:
> > 
> > Unfortunately, I'm not sure how useful the backtrace this is, since this
> > looks basically like one of those segfaults in malloc, which means there's
> > random memory corruption elsewhere.
> > 
> > Alex, are you currently able to run Purify on innd?
> > 
> 
> Yes & no - my build tree is in tatters (doing the history stuff), but
> I'll try hauling out a fresh copy & leave it running on my development
> box tomorrow.
> 

Well Purify's showing nothing interesting (apart from the two
non-critical leaks I just posted a patch for), and a read of
uninitialised memory in buffindexed when its writing a structure with
a hole in it to disk (which I don't intend fixing, since I don't
really consider it a bug - I might add an ifdef PURIFY):

UMR: Uninitialized memory read (139 times):
  * This is occurring while in:
	_pwrite64      [libc.so.1]
	ovsetcurindexblock [buffindexed.c:1222]
	ovaddrec       [buffindexed.c:1320]
	buffindexed_add [buffindexed.c:1397]
	OVadd          [ov.c:317]
	ARTpost        [art.c:2594]
  * Reading 16 bytes from 0xffbef200 on the stack (2 bytes at 0xffbef206 uninit).
  * Address 0xffbef200 is local variable "ovindexhead" in function ovsetcurindexblock.

Looking at the problem posts though, they seem to have perl filtering
enabled (I'm not), and its not clear if they're for feeds which have
already been ARTclean()ed (I'm taking a single feed from an INN 2.3
transit server). If anyone wants to push a dirty feed at me, you're
more than welcome to.

I'll try playing with perl filtering.

-- 
Alex Kiernan, Principal Engineer, Development, Thus PLC