3

It appears this only occurs when using Java 1.7, either with the Oracle or OpenJDK JRE. Everything works find when using Java 1.6 (both Oracle and OpenJDK).

A while ago, I tried compiling a JNI shared library (a wrapper around LibVLC used for a Java movie player) under Linux. However, when calling certain native functions, the JVM crashed at sporadic and arbitrary moments, with the error log citing the function _IO_file_underflow from libc.so as the problematic frame.

Eventually I found out I was simply missing some GCC flags while compiling, and the problems were probably caused by certain optimizations or such the JVM did not expect. After following this guide and the answer to this question I added some flags such as -fno-strict-aliasing and -pthread to the compilation command, and everything worked perfectly.

At least, this worked under OpenSuSe 12.1 with OpenJDK 1.6. Unfortunately, after having upgraded to OpenSuse 12.2 and OpenJDK 1.7, the application started crashing again with the following familiar error message:

#
[thread -1984603328 also had an error]# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0xb770ff38, pid=19354, tid=2309835584
#
# JRE version: 7.0_09-b30
# Java VM: OpenJDK Client VM (23.2-b09 mixed mode linux-x86 )
# Problematic frame:
# C  [libc.so.6+0x127f38]  _IO_file_underflow+0x68
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# An error report file with more information is saved as:
# /usr/fids/build_vlcplayer/hs_err_pid19354.log

#
# If you would like to submit a bug report, please include
# instructions on how to reproduce the bug and visit:
#   http://icedtea.classpath.org/bugzilla
#

I'm using the following command to compile (many of the flags are probably redundant):

gcc -I/usr/lib/jvm/java-1.7.0-openjdk-1.7.0/include/ -I/usr/lib/jvm/java-1.7.0-openjdk-1.7.0/include/linux/ -fno-strict-aliasing -fno-omit-frame-pointer -fPIC -pthread -static-libgcc -D_REENTRANT -Di586 -DARCH='"I586"' -DLINUX -D_LARGEFILE64_SOURCE -D_GNU_SOURCE -D_LITTLE_ENDIAN  -Wall -Wno-unused-parameter -DDEBUG_MODE -shared -lvlc -lc -lX11 movieplayer.c -Wl,-soname,movieplayer.so -o movieplayer.so

I've tried this with both GCC version 3.3 and version 4.7.

Since the same code works fine under Windows (with Oracle JDK 1.6 or 1.7) or OpenSuSe 12.1 (with OpenJDK 1.6), I don't think the actual source code of movieplayer.c is relevant; nonetheless, here is the part where the crashes occur:

/** The LibVLC instance.*/
static libvlc_instance_t * vlcInstance = NULL;

/** The media object representing the video. */
static libvlc_media_t * media = NULL;

/** The media player. */
static libvlc_media_player_t * mediaPlayer = NULL;

...

const char * fname = str + 1;

DEBUGMSG("Opening file: '%s'\n", fname);

// Create a VLC media object for this file.
media = libvlc_media_new_path (vlcInstance, fname);

if(media)
{
    // Parse the media. This allows fetching duration and track info.
    DEBUGMSG("Parsing media.");
    libvlc_media_parse(media);  // <-- Crash occurs at this point.

    // Create the media player.
    DEBUGMSG("Creating a media player.");
    mediaPlayer = libvlc_media_player_new_from_media(media);

    ...
}

...

When I modify this code, the same crash occurs at different moments when calling other LibVLC-functions or, in one case, when calling the POSIX sleep function.

Basically my question is: am I correct in thinking that these crashes are caused because I am not compiling the application correctly? If so, what am I doing wrong?

Community
  • 1
  • 1
AardvarkSoup
  • 1,071
  • 8
  • 18
  • 3
    static JNI objects + multi-threaded JRE == soul destroying agony of random crashes. I would recommend bundling all the static pointers into an struct/pointer that is allocated and returned to java from C, and passed back when being used by the JNI code. – Anya Shenanigans Dec 11 '12 at 16:37
  • If statics are indeed the problem, that might be a good solution. I will give this a shot. – AardvarkSoup Dec 15 '12 at 14:14
  • Nope, that did not work. I did find out that this only occurs in JRE version 1.7 but not 1.6. – AardvarkSoup Dec 18 '12 at 10:31
  • I would also like to add that all JNI calls are done from a single thread. – AardvarkSoup Dec 18 '12 at 10:32
  • Did you end up having any luck with this? I believe I am experiencing something similar. I did try switching to java 1.6 but my random crash occurred still. – khendricks Dec 21 '13 at 21:42
  • @khendricks: nope. Due to this and a number of other issues and impracticalities with JNI (including that 64-bit JVM's can not load 32-bit shared libraries and that JNI code is difficult to debug), we decided to instead compile the C code to an executable, start that as a child process of the Java app, and communicate with it through stdin/stdout. I still did not succeed in solving this particular issue. – AardvarkSoup Dec 22 '13 at 13:24

1 Answers1

1

Here is a discussion about the same issue: https://github.com/caprica/vlcj/issues/62 with a workaround: disable LUA in VLC. Somehow the Ubuntu packaging broke it. There are references to furter pages which discuss it too. See also https://bugs.launchpad.net/ubuntu/+source/lua5.1/+bug/1136432.

Olaf Seibert
  • 151
  • 7