Here is another backtrace with a debug build of JCC.
#10 <signal handler called>
#11 0x00002b05b2cf4c74 in JNIEnv_::DeleteGlobalRef (this=0x0,
gref=0x2b05d02e0250) at /opt/vlspy27/lib/jdk1.6/include/jni.h:830
#12 0x00002b05b2cf0ce5 in JCCEnv::deleteGlobalRef (this=0x360f650,
obj=0x2b05d02e0250, id=1351575229) at jcc/sources/JCCEnv.cpp:321
#13 0x00002b05b2522649 in t_JObject_dealloc(t_JObject*) ()
from
/opt/vlspy27/lib/python2.7/site-packages/lucene-3.1.0-py2.7-linux-x86_64.egg/lucene/_lucene.so
#14 0x00002b05a303b1eb in dict_dealloc (mp=0xa2d1e20) at
Objects/dictobject.c:985
#15 0x00002b05a303cedb in PyDict_Clear (op=<value optimized out>) at
Objects/dictobject.c:891
#16 0x00002b05a303cf49 in dict_tp_clear (op=0x0) at
Objects/dictobject.c:2088
#17 0x00002b05a30ddb7e in delete_garbage (generation=<value optimized
out>) at Modules/gcmodule.c:769
#18 collect (generation=<value optimized out>) at Modules/gcmodule.c:930
#19 0x00002b05a30de3ae in collect_generations (basicsize=<value
optimized out>) at Modules/gcmodule.c:996
#20 _PyObject_GC_Malloc (basicsize=<value optimized out>) at
Modules/gcmodule.c:1457
#21 0x00002b05a30de44d in _PyObject_GC_New (tp=0x2b05a334dfa0) at
Modules/gcmodule.c:1467
#22 0x00002b05a303abbc in PyDict_New () at Objects/dictobject.c:277
#23 0x00002b05a303c846 in _PyDict_NewPresized (minused=0) at
Objects/dictobject.c:677
#24 0x00002b05a30a3088 in PyEval_EvalFrameEx (f=0x5302b10,
throwflag=<value optimized out>) at Python/ceval.c:2220
#25 0x00002b05a30a88b8 in PyEval_EvalCodeEx (co=0x23c2ab0,
globals=<value optimized out>, locals=<value optimized out>, args=0x66c74c8,
argcount=<value optimized out>, kws=<value optimized out>,
kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:3252
As you can clearly see, the JNIEnv_ instance is a NULL pointer. Contrary
to my initial assumption, the thread doesn't have a JCC thread local
object. Since any thread may trigger a GC collect run, and not just
threads, that use JCC, this looks like a bug in JCC to me.
Christian
