Latest core dump ... newest CVS ...

[The Hermit Hacker]

based on that theory, how can/does one disabled perl filtering
temporarily, to see if that fixes it?

On 12 Feb 2001, Alex Kiernan wrote:

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

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy at hub.org           secondary: scrappy@{freebsd|postgresql}.org