Redhat AS 4 seg fault calling magic_buffer using Java 1.6

Question

I have a java class that calls a C++ class via a JNI C++ class to access the 'file' command functionality provided by libmagic.so.

• The C++ class compiles and run fine as a C++ main()

-It works fine on RHEL 5 running java 1.5 and 1.6;

-it works fine on RHEL 4 running java 1.5

-it throws a seg fault 26234 on the RHEL 4 with java 1.6

The seg fault:

1. Occurs at the call char* retptr = magic_buffer(cookie, bigbuf, 1000); No fault when char* retptr = “a nice safe character string”; is substituted. This is why I conclude that the seg fault occurs at this call.

2. I use an alternative call, char* retptr = magic_file(cookie,”/usr/include/magic.h”); to debug buffer problems, as this call returns the same file type message requiring only the fully qualified path name of the file, rather than a buffer full of the file content. It also throws the seg fault on the RHEL4/java 1.6 test VM. Thus, I conclude the problem does not appear to be bad pointers or overflowing buffers in my code.

3. magic_buffer is a call to libmagic.so. In the code previously, other successful calls to this lib are made. This call, however, involves the lib magic database /usr/share/file/magic.

4. Compiling the C++ as an executable and running it on the problem machine works just fine.

Here's some conclusions:

A. There is JNI involvement, because of #4

B. Because of #1/#2, I don't believe it is a JNI implementation issue.

C. Because of #1, #2, and #4 I don't believe it is a c++ implementation issue.

Any suggestions or comments? (initially run on VMWare, now tested with no VM involvement)

Answer 1

My first suggestion is to try and find a pure Java alternative. This page lists a number of alternatives. Apache Tika and JMimeMagic look promising.

My second suggestion is to use Process to run the file command in a separate process and scrape the information you need from the command's standard output. This may have (ahem) performance issues if you need to do this hundreds of times a second, but for occasional use it should be fine.