On Sun, Jan 24, 2010 at 10:27:15PM -0600, Peter Karman wrote:
> I will try and reduce the size of the doc collection in question to see if
> I can make a reproducable test case.
Hold up a sec...
That might be a little tricky, since it's almost certainly tied to flushing of
sorted runs. If you drop below the threshold where runs get flushed, you may
not see the problem any more.
I see from this that the problem is a call to free() from within
SortEx_destroy():
> #4 0x00000030caf691f6 in free () from /lib64/tls/libc.so.6
> #5 0x0000002a990eebc1 in kino_SortEx_destroy ()
> from
> /opt/pij/lib/perl5/site_perl/5.8.9/x86_64-linux/auto/KinoSearch/KinoSearch.so
> #6 0x0000002a99144656 in kino_Obj_dec_refcount ()
> from
> /opt/pij/lib/perl5/site_perl/5.8.9/x86_64-linux/auto/KinoSearch/KinoSearch.so
> #7 0x0000002a990f79e4 in kino_PostWriter_finish ()
> from
> /opt/pij/lib/perl5/site_perl/5.8.9/x86_64-linux/auto/KinoSearch/KinoSearch.so
> #8 0x0000002a99104657 in kino_SegWriter_finish ()
That's a little weird because all calls to free() should be wrapped by
Memory_wrapped_free().
SortEx_destroy isn't very long, though:
void
SortEx_destroy(SortExternal *self)
{
FREEMEM(self->scratch);
FREEMEM(self->slice_sizes);
FREEMEM(self->slice_starts);
if (self->cache) {
SortEx_Clear_Cache(self);
FREEMEM(self->cache);
}
DECREF(self->runs);
SUPER_DESTROY(self, SORTEXTERNAL);
}
We should try to hunt this down logically before spending too much time on
reproducing it.
Marvin
