Segmentation fault when using some IPP routine from a JNI interface

[georgiswan]

Hello,

I am not sure whether this is the right place to ask this question since it is related to both JNI and IPP.

When I run a few IPP routines (ex: ippiFilter, ippiRectStdDev) from a JNI interface, I get this message :

~~~~
Warning: SIGSEGV handler expected:libjvm.so+0x594f90 found:libguide.so+0x486ec
Signal Handlers:
SIGSEGV: [libguide.so+0x486ec], sa_mask[0]=0x7ffbfeff, sa_flags=0x00000000
SIGBUS: [libguide.so+0x486ec], sa_mask[0]=0x7ffbfeff, sa_flags=0x00000000
SIGFPE: [libguide.so+0x486ec], sa_mask[0]=0x7ffbfeff, sa_flags=0x00000000
SIGPIPE: [libguide.so+0x486ec], sa_mask[0]=0x7ffbfeff, sa_flags=0x00000000
SIGXFSZ: [libjvm.so+0x594f90], sa_mask[0]=0x7ffbfeff, sa_flags=0x10000004
SIGILL: [libguide.so+0x486ec], sa_mask[0]=0x7ffbfeff, sa_flags=0x00000000
SIGUSR1: SIG_DFL, sa_mask[0]=0x00000000, sa_flags=0x00000000
SIGUSR2: [libjvm.so+0x597750], sa_mask[0]=0x00000000, sa_flags=0x10000004
SIGHUP: [libguide.so+0x486ec], sa_mask[0]=0x7ffbfeff, sa_flags=0x00000000
SIGINT: [libguide.so+0x486ec], sa_mask[0]=0x7ffbfeff, sa_flags=0x00000000
SIGTERM: [libguide.so+0x486ec], sa_mask[0]=0x7ffbfeff, sa_flags=0x00000000
SIGQUIT: [libguide.so+0x486ec], sa_mask[0]=0x7ffbfeff, sa_flags=0x00000000
Warning: SIGILL handler expected:libjvm.so+0x594f90 found:libguide.so+0x486ec
Signal Handlers:
SIGSEGV: [libguide.so+0x486ec], sa_mask[0]=0x7ffbfeff, sa_flags=0x00000000
SIGBUS: [libguide.so+0x486ec], sa_mask[0]=0x7ffbfeff, sa_flags=0x00000000
....
~~~~

However, running the exact same thing from a straight C++ program works fine. This happens only on a Linux64 computer (I have no problem under windows).

I am not sure whether this message really means a segmentation fault because when I create a real one on purpose, I get this:

~~~
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00002aaad63ae71f, pid=17178, tid=1094490432
#
# JRE version: 6.0_16-b01
# Java VM: Java HotSpot 64-Bit Server VM (14.2-b01 mixed mode linux-amd64 )
# Problematic frame:
# C [libmyJNI.so+0x71f] Java_IPP_StdDev_TestStdDev+0x13
#
# An error report file with more information is saved as:
# /home/gsoucy/SVN/C++/Applications/Test/Test_ImageIO/hs_err_pid17178.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
~~~

which is much more clear.

I cut my program to the minimum to test the problem, here it is:

~~~
// integral image
int width = 500;
int height = 500;
int srcStep = width*4;
Ipp32f* pSrc = (Ipp32f*) malloc(srcStep * height);

// sqr integrsal image
int sqrHeight = height;
int sqrWidth = width;
int sqrStep = sqrWidth*8;

Ipp64f* pSqr = (Ipp64f*) malloc(sqrStep * sqrHeight);

// dst image
IppiRect rect = {0, 0, 20, 20};
IppiSize roi = {width-rect.width-1, height-rect.height-1};

int dstHeight = roi.height;
int dstWidth = roi.width;
int dstStep = dstWidth * 4;

Ipp32f* pDst = (Ipp32f*) malloc(dstStep * dstHeight);



IppStatus ret = ippiRectStdDev_32f_C1R(pSrc, srcStep, pSqr, sqrStep, pDst, dstStep, roi, rect);

if (ret == ippStsOk)
printf("Ok!!\n");
else
printf("Failed!! (%d)\n", ret);
~~~

I use exactly the same code in the straight C++ and in the JNI programs: it works without any error message in C++ and complains about the error handlers in JNI.

Anybody sees what I am doing wrong? Any help would be appreciated.

Thanks!

Gilbert

[Vladimir_Dudnik]

It looks like you use old Intel OpenMP run time library (libguide)somewhere in your application. This is not compatible with the latest Intel OpenMP library (libiomp5) which was used in IPP 6.1 build.

So if you can move to new OpenMP run time this problem should be fixed. Otherwise there is no way to use both OpenMP run time libraries in single application

Regards,
Vladimir

[georgiswan]

Quoting - Vladimir Dudnik (Intel)

It looks like you use old Intel OpenMP run time library (libguide)somewhere in your application. This is not compatible with the latest Intel OpenMP library (libiomp5) which was used in IPP 6.1 build.

So if you can move to new OpenMP run time this problem should be fixed. Otherwise there is no way to use both OpenMP run time libraries in single application

Regards,
Vladimir

Thanks for the reply Vladimir.

You are right, I was using libguide. I changed my Makfile to use libiomp5 but I still get the same error (I can see that my program is now using libiomp5 with 'ldd'). I think that this is a JNI problem. I will try to see on that side. Thanks.

[Andreas_Muesing]

Quoting - georgiswan

Thanks for the reply Vladimir.

You are right, I was using libguide. I changed my Makfile to use libiomp5 but I still get the same error (I can see that my program is now using libiomp5 with 'ldd'). I think that this is a JNI problem. I will try to see on that side. Thanks.

Hello,

i had a quite similar problem with intel mkl and java (32-bit Linux) . The jvm crash was exactly looking as yours, and I
really spent a lot of time to figure out what happened. The solution that worked for me:
- the JVM is using the same signals (SIGSEGV , ...) as intel mkl is using. Then, the jvm crashes, because it interprets mkl's signals
wrong.
After simply including the libjsig.so library with the environment variable export LD_PRELOAD=/libjsig.so
everything was working fine. I hope this helps also for your issue.

Regards,
Andreas.

[nonamez]

Quoting - Andreas Muesing

Hello,

i had a quite similar problem with intel mkl and java (32-bit Linux) . The jvm crash was exactly looking as yours, and I
really spent a lot of time to figure out what happened. The solution that worked for me:
- the JVM is using the same signals (SIGSEGV , ...) as intel mkl is using. Then, the jvm crashes, because it interprets mkl's signals
wrong.
After simply including the libjsig.so library with the environment variable export LD_PRELOAD=/libjsig.so
everything was working fine. I hope this helps also for your issue.

Regards,
Andreas.

my problems code

[Andrei_Moskalev__Int]

Folks,

The issues (with signal handling by libiomp5) described in the previous posts were resolved in Composer 2011 beta update 2 and Compiler Pro 12.0 beta update 1. Now the defualt behaviour of libiomp is do nothandle signals. But it can be turned on by setting (environment variable) KMP_HANDLE_SIGNALS to 1. Please, try to run your tests with using the latest Composer (at least Composer 2011 beta update 2 or Compiler Pro 12.0 beta update 1) .

--andrew