Question

我正在编写一个Java应用程序，我从Cuneiform OCR库调用（通过另一个库）函数。不幸的是，我在一个非常奇怪的地方遇到了崩溃，我需要社区的建议。

程序在RVERLINE_MarkLines()的第一个代码行崩溃，从RSL_SetImportData()调用，处于第一个代码位置（变量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

其他信息：

Platform Linux x32
SUN JVM 1.6.0.22
GCC 4.4.5

Answer 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]

楔形文库在通过JNI桥调用时崩溃

1 个答案: