-
Notifications
You must be signed in to change notification settings - Fork 8
Description
When compiling a table with includes that are more than 6 levels deep the JVM crashes with SIGBUS
According to the internets SIGBUS is generally related to memory problems, so the first thought is of course to blame liblouis and to assume that it is writing over some JVM stack frames.
Options
- liblouis is somehow corrupting the memory
- The Java bindings have a problem
- some other problem
Analysis
liblouis is corrupting memory
- Port the test to C so we can analyze the memory.
- Run Valgrind on the C test case
- Analyze C test case with Electric Fence
So @bertfrees ported the test case to C, see https://github.com/liblouis/liblouis/blob/test_deep_include/tests/deep_include.c. When running Valgrind there is a memory leak around the usage of the DefaultTableResolver
. Electric Fence does not indicate any problems whatsoever.
The problem persists on the JVM when using a liblouis where the memory leak is fixed
Java bindings have a problem
It is not clear where there could be a problem here. The test case simply invokes get_Table
through a very simple API straight down to C.
- Run gdb on the Java test case: doesn't give much info except that the SIGBUS happens in compileUplow on the line
int haveLowerDots = 0
(may not mean anything). - Run valgrind on the Java test case. Maybe this will give us a hint if JVM or JNA are doing something fishy.
Other problem
Some findings from a google search indicate that the problem could be within the JVM and the use of mmaped files
- Try to reproduce the problem on an other machine
On a Linux machine the problem doesn't occur