[Xapian-discuss] upgraded 1.0.19 to 1.2.0 - indexing seems to be getting stuck

Olly Betts olly at survex.com
Wed Jun 2 08:04:42 BST 2010


On Wed, Jun 02, 2010 at 08:21:03AM +0200, Per Jessen wrote:
> Olly Betts wrote:
> 
> > On Tue, Jun 01, 2010 at 06:14:07PM +0200, Per Jessen wrote:
> >> Today I upgraded to 1.2.0 - and my indexing jobs are now getting hung
> >> up.  They appear to be waiting on a futex.  Not everyone, but every
> >> now and then.  I'll try to get some diagnostics.
> > 
> > Some more details would be useful too - you don't even mention the OS
> > or language you're using (though I guess Linux if you have futexes). 
> 
> Sorry, I tend to forget that.  I'm on Linux and using C++.  I have
> written a indexing utility that reads files from disk, parses the
> contents and indexes them. 

Is this run from the command line?  Does it use threads?

> > If you can, attach gdb to the stuck process and get a backtrace (bt).
> 
> Not of much use, I suspect:
> 
> 0xffffe430 in __kernel_vsyscall ()
> (gdb) bt
> #0  0xffffe430 in __kernel_vsyscall ()
> #1  0x40604643 in ?? () from /lib/libc.so.6
> #2  0x4059ad71 in ?? () from /lib/libc.so.6
> Backtrace stopped: previous frame identical to this frame (corrupt
> stack?)
> 
> > I've not seen anything like this myself.  We don't directly use
> > futexes or threading on Unix platforms, so it's not obvious where to
> > look without more information.
> 
> Interestingly, it seems to be waiting for a fork()ed "/bin/cat" which
> seems to be happening in backends/flint_lock.cc ?

That process holds the write lock on the database (to protect us from the less
helpful semantics of fcntl locking).

This has tripped up people running under selinux before, so if you're using
selinux you might need to update your policy for processes using Xapian.

Cheers,
    Olly



More information about the Xapian-discuss mailing list