java - Cuneiform library crashes when is called via JNI bridge -

i writing java application, call (via library) functions cuneiform ocr library. unfortunately, have crash in strange place, , need advice of community.

the program crashes on first code line of rverline_marklines(), called rsl_setimportdata(), in first code position (initialization of variable lti). have checked passed variables in gdb: make sense , seem valid. looks stack corrupted, tried reshuffle source lines in rverline_marklines() without success.

the same code same input data works ok when invoked c++ code (cpp cli → library → cuneiform library), breaks when invoked jvm (jvm → library → cuneiform library).

as newbie gdb, perhaps can give me hint, how can find out reason of crash? @ , pay attention to?

many in advance.

stack trace:

program received signal sigsegv, segmentation fault. [switching thread 0xb7564b70 (lwp 416)] rverline_marklines (hccomp=0xb28a2708, hcpage=0xb28a28d0)     @ cuneiform-1.0.0.orig/cuneiform_src/kern/rverline/src/root/vl_kern.cpp:120 120             linestotalinfo  lti = {0};  // Структура хранения линий (gdb) bt #0  rverline_marklines (hccomp=0xb28a2708, hcpage=0xb28a28d0)     @ cuneiform-1.0.0.orig/cuneiform_src/kern/rverline/src/root/vl_kern.cpp:120 #1  0xb3b7d727 in rsl_setimportdata (dwtype=1, pdata=0xb7559b50)     @ cuneiform-1.0.0.orig/cuneiform_src/kern/rshelllines/src/rshelllines.cpp:332 #2  0xb3bdca96 in rline_linespass1 (hcpage=0xb28a28d0, hccom=0xb28a2708, phcline=0xb45a34fc, pgneed_clean_line=0xb45a3630, sdl=0,     lang=0 '\000') @ cuneiform-1.0.0.orig/cuneiform_src/kern/rline/sources/newline.cpp:224 #3  0xb3b70bb2 in searchnewlines (image=0xb7559e1c)     @ cuneiform-1.0.0.orig/cuneiform_src/kern/rstuff/sources/main/normalise.cpp:230 #4  0xb3b70d78 in normalise (image=0xb7559e1c)     @ cuneiform-1.0.0.orig/cuneiform_src/kern/rstuff/sources/main/normalise.cpp:189 #5  0xb3b6d900 in rstuff_rsnormalise (image=0xb7559e1c, vbuff=0xb31ba008, size=500000, vwork=0xb318e008, sizework=180000)     @ cuneiform-1.0.0.orig/cuneiform_src/kern/rstuff/sources/main/dll.cpp:352 #6  0xb458919a in layout (lpdata=0x0) @ cuneiform-1.0.0.orig/cuneiform_src/kern/puma/c/partlayout.cpp:203 #7  0xb458b963 in puma_xfinalrecognition () @ cuneiform-1.0.0.orig/cuneiform_src/kern/puma/main/puma.cpp:590 ... #20 0xb77d5d0c in jni_callstaticvoidmethod () /usr/lib/jvm/java-6-sun-1.6.0.22/jre/lib/i386/client/libjvm.so #21 0x08049b98 in javamain () #22 0xb7fc3955 in start_thread (arg=0xb7564b70) @ pthread_create.c:300 #23 0xb7f35e7e in clone () @ ../sysdeps/unix/sysv/linux/i386/clone.s:130 

additional info:

• platform linux x32
• sun jvm 1.6.0.22
• gcc 4.4.5

your crash looks typical case of stack exhaustion.

when call library c++, use main thread, has @ least 8mb. when call java, call thread other main, may have smaller stack (for example, for linux x32 default stack size 320k – may vary different platforms , different jvm implementations).

the following commands should allow confirm problem:

(gdb) p/x $esp (gdb) shell cat /proc/<pid>/maps  # replace <pid> pid of crashing                                   # thread, e.g. 416 above. 

you see $esp points inaccessible (guard) page (which has ---p permissions). if correct, must either create thread uses ocr library larger stack, or ensure library accessed main thread. can using e.g. -xss1024k jvm argument (will set stack size threads) or -xx:mainthreadstacksize=1024k (will set stack size main thread on hp-ux jvm).

for example ok $esp value 0xb755a000 within memory segment (has rw permissions):

b7517000-b7565000 rwxp 00000000 00:00 0          [threadstack:0004d494]