通过 JNI 桥调用楔形文字库时崩溃答案

【问题标题】：Cuneiform library crashes when is called via JNI bridge通过 JNI 桥调用楔形文字库时崩溃
【发布时间】：2011-02-18 16:24:15
【问题描述】：

我正在编写一个 Java 应用程序，我从中调用（通过另一个库）来自 Cuneiform OCR 库的函数。不幸的是，我在一个非常陌生的地方发生了车祸，我需要社区的建议。

程序在从RSL_SetImportData() 调用的RVERLINE_MarkLines() 的第一行代码处崩溃，位于最开始的代码位置（变量lti 的初始化）。我检查了gdb 中所有传递的变量：它们都有意义并且似乎是有效的。看起来堆栈已损坏，因为试图重新洗牌 RVERLINE_MarkLines() 中的源代码行但没有任何成功。

当从 C++ 代码（CPP CLI → 一些库 → Cuneiform 库）调用时，相同输入数据的相同代码可以正常工作，但从 JVM（JVM → 一些库 → Cuneiform 库）调用时会中断。

我是gdb的新手，也许有人可以给我一个提示，我怎样才能找出崩溃的原因？在哪里看，要注意什么？

非常感谢。

堆栈跟踪：

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb7564b70 (LWP 416)]
RVERLINE_MarkLines (hCComp=0xb28a2708, hCPage=0xb28a28d0)
    at 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)
    at cuneiform-1.0.0.orig/cuneiform_src/Kern/rverline/src/root/vl_kern.cpp:120
#1  0xb3b7d727 in RSL_SetImportData (dwType=1, pData=0xb7559b50)
    at 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') at cuneiform-1.0.0.orig/cuneiform_src/Kern/rline/sources/newline.cpp:224
#3  0xb3b70bb2 in SearchNewLines (Image=0xb7559e1c)
    at cuneiform-1.0.0.orig/cuneiform_src/Kern/rstuff/sources/main/normalise.cpp:230
#4  0xb3b70d78 in Normalise (Image=0xb7559e1c)
    at 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)
    at cuneiform-1.0.0.orig/cuneiform_src/Kern/rstuff/sources/main/dll.cpp:352
#6  0xb458919a in Layout (lpdata=0x0) at cuneiform-1.0.0.orig/cuneiform_src/Kern/puma/c/partlayout.cpp:203
#7  0xb458b963 in PUMA_XFinalRecognition () at cuneiform-1.0.0.orig/cuneiform_src/Kern/puma/main/puma.cpp:590
...
#20 0xb77d5d0c in jni_CallStaticVoidMethod () from /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) at pthread_create.c:300
#23 0xb7f35e7e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130

附加信息：

平台 Linux x32
SUN JVM 1.6.0.22
GCC 4.4.5

【问题讨论】：

标签： java gdb java-native-interface shared-libraries

【解决方案1】：

您的崩溃看起来像是堆栈耗尽的典型案例。

当您从 C++ 调用库时，您可能使用主线程，通常至少有 8MB。当您从 Java 调用它时，您是从除 main 之外的某个线程调用它，该线程可能有一个小得多的堆栈（例如，for Linux x32 default stack size is 320k - 对于不同的平台和不同的 JVM 实现可能会有所不同）。

以下命令应该可以让您确认问题：

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

您可能会看到$esp 指向不可访问（保护）页面（具有---p 权限）。如果这是正确的，您必须创建使用具有更大堆栈的 OCR 库的线程，或者确保仅从主线程访问该库。您可以使用例如-Xss1024K JVM 参数（将为所有线程设置堆栈大小）或-XX:MainThreadStackSize=1024K（将为 HP-UX JVM 上的主线程设置堆栈大小）。

例如$esp 值0xb755a000 可以在此内存段内（具有rw 权限）：

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

【讨论】：