It looks like one of the indices (the first one opened, actually) is missing its segments file. Why this causes the abort several indices later is a bit of a mystery, but I can at least work around this.
A bug posted to the gcj bug tracker in 2000 indicated that sometimes null exceptions weren't being propogated correctly and were just causing aborts, but I assume this is fixed by now. Maybe the PyLucene wrappers could have a catch-all for null pointer exceptions though, so that aborts are prevented? I don't know how ugly that would get, but aborts aren't good either. On 31/01/06, tsuraan <[EMAIL PROTECTED]> wrote: > I have a MultiSearcher being created off of several indices on my > computer. It generally works, but sometimes I get an abort, with the > following backtrace (in the thread that I assume caused the abort) > > Thread 3 (Thread 4 (LWP 100120)): > #0 0x2822f31b in pthread_testcancel () from /usr/lib/libpthread.so.1 > #1 0x28220145 in sigaction () from /usr/lib/libpthread.so.1 > #2 0x2821a1dd in pthread_kill () from /usr/lib/libpthread.so.1 > #3 0x28219bac in raise () from /usr/lib/libpthread.so.1 > #4 0x282eac1b in abort () from /lib/libc.so.5 > #5 0x28c7000c in _Jv_Throw (value=0x89753f0) > at ../../../gcc-4.1-20051029/libjava/exception.cc:111 > #6 0x28c64873 in _Jv_ThrowNullPointerException () > at ../../../gcc-4.1-20051029/libjava/prims.cc:359 > #7 0x08391e28 in ?? () > #8 0x2847c7c7 in org::apache::lucene::store::FSIndexInput::close () > from /vault/lib/_PyLucene.so > #9 0x2847c819 in org::apache::lucene::store::FSIndexInput::finalize () > from /vault/lib/_PyLucene.so > #10 0x28c99c36 in _Jv_FinalizeObject (obj=0x837dea0) > at ../../../gcc-4.1-20051029/libjava/java/lang/natObject.cc:121 > #11 0x28ca36e2 in call_finalizer (obj=0x837dea0, client_data=0x28c99c18) > at ../../../gcc-4.1-20051029/libjava/boehm.cc:527 > #12 0x29179e1c in GC_invoke_finalizers () > at ../../../gcc-4.1-20051029/boehm-gc/finalize.c:787 > #13 0x28ca3a15 in _Jv_RunFinalizers () > at ../../../gcc-4.1-20051029/libjava/boehm.cc:540 > #14 0x28c8f827 in gnu::gcj::runtime::FinalizerThread::run (this=0x82ecb40) > at > ../../../gcc-4.1-20051029/libjava/gnu/gcj/runtime/natFinalizerThread.cc:60 > #15 0x28c9e256 in _Jv_ThreadRun (thread=0x82ecb40) > at ../../../gcc-4.1-20051029/libjava/java/lang/natThread.cc:299 > #16 0x28ca4f9d in really_start (x=0x29183264) > at ../../../gcc-4.1-20051029/libjava/posix-threads.cc:398 > #17 0x08361ff8 in ?? () > #18 0x29183264 in GC_start_routine (arg=0x82cefe0) > at ../../../gcc-4.1-20051029/boehm-gc/pthread_support.c:1185 > #19 0x2821baf1 in pthread_create () from /usr/lib/libpthread.so.1 > #20 0x282d6253 in _ctx_start () from /lib/libc.so.5 > > > The code isn't interesting; it opens a few IndexSearchers and attempts > to put them into a MultiSearcher. The crash happens during the > creation of a specific IndexSearcher, every time. If I open python > command line and open the index myself, it works fine. The only > difference that I can think of is that my program is running > multi-threaded with SOAPpy, but I am overriding threading.Thread with > PyLucene.PythonThread. Any suggestions in tracking this one down > would be appreciated. > _______________________________________________ pylucene-dev mailing list [email protected] http://lists.osafoundation.org/mailman/listinfo/pylucene-dev
