Unexpected Signal 10 when GC runs while in native code

Question

I submitted the following bug but didn't get an answer. Can anyone reproduce this? Is it a bug or do we make something wrong?
description: FULL PRODUCT VERSION :
java version "1.4.2_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_05-b04)
Java HotSpot(TM) 64-Bit Server VM (build 1.4.2_05-b04, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
SunOS 5.8 Generic_117000-03 sun4u sparc SUNW,Sun-Fire-V440
EXTRA RELEVANT SYSTEM CONFIGURATION :
g++ --version:
g++ (GCC) 3.3.2
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
A DESCRIPTION OF THE PROBLEM :
If the GC-Thread runs while another Thread is in a native method, then the GC Thread crashes with unexpected Signal 10. This problem happens only in some circumstances where the order, the types and the values of the parameters passed to the native method are important.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
please see attached source.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
no crash
ACTUAL -
Unexpected Signal 10 (GC Thread)
ERROR MESSAGES/STACK TRACES THAT OCCUR :
Unexpected Signal : 10 occurred at PC=0xFFFFFFFF7D1A81E8
Function=[Unknown. Nearest: JVM_ArrayCopy+0x108F0]
Library=/home/shm/java/j2sdk1.4.2_05/jre/lib/sparcv9/server/libjvm.so
Dynamic libraries:
0x100000000 java
0xffffffff7f300000 /usr/lib/64/libthread.so.1
0xffffffff7f500000 /usr/lib/64/libdl.so.1
0xffffffff7ef00000 /usr/lib/64/libc.so.1
0xffffffff7f100000 /usr/platform/SUNW,Sun-Fire-V440/lib/sparcv9/libc_psr.so.1
0xffffffff7d000000 /home/shm/java/j2sdk1.4.2_05/jre/lib/sparcv9/server/libjvm.so
0xffffffff7d900000 /usr/lib/64/libCrun.so.1
0xffffffff7ce00000 /usr/lib/64/libsocket.so.1
0xffffffff7cc00000 /usr/lib/64/libnsl.so.1
0xffffffff7ca00000 /usr/lib/64/libm.so.1
0xffffffff7c800000 /usr/lib/64/libsched.so.1
0xffffffff7db00000 /usr/lib/64/libw.so.1
0xffffffff7c400000 /usr/lib/64/libmp.so.2
0xffffffff7c100000 /home/shm/java/j2sdk1.4.2_05/jre/lib/sparcv9/native_threads/libhpi.so
0xffffffff7bd00000 /home/shm/java/j2sdk1.4.2_05/jre/lib/sparcv9/libverify.so
0xffffffff7ba00000 /home/shm/java/j2sdk1.4.2_05/jre/lib/sparcv9/libjava.so
0xffffffff7b800000 /home/shm/java/j2sdk1.4.2_05/jre/lib/sparcv9/libzip.so
0xffffffff2f600000 /usr/lib/locale/en_US.ISO8859-1/sparcv9/en_US.ISO8859-1.so.2
0xffffffff2e100000 /home/shm/test/javasetlong/libjni01.so
0xffffffff2d900000 /usr/lib/64/libpthread.so.1
0xffffffff2d700000 /usr/local/lib/sparcv9/libstdc++.so.5
0xffffffff2d500000 /usr/local/lib/sparcv9/libgcc_s.so.1
Heap at VM Abort:
Heap
def new generation total 2112K, used 168K [0xffffffff2f800000, 0xffffffff2fa20000, 0xffffffff30d50000)
eden space 2048K, 8% used [0xffffffff2f800000, 0xffffffff2f82a0b8, 0xffffffff2fa00000)
from space 64K, 0% used [0xffffffff2fa00000, 0xffffffff2fa00000, 0xffffffff2fa10000)
to space 64K, 0% used [0xffffffff2fa10000, 0xffffffff2fa10000, 0xffffffff2fa20000)
tenured generation total 1408K, used 0K [0xffffffff30d50000, 0xffffffff30eb0000, 0xffffffff33800000)
the space 1408K, 0% used [0xffffffff30d50000, 0xffffffff30d50000, 0xffffffff30d50200, 0xffffffff30eb0000)
compacting perm gen total 16384K, used 1522K [0xffffffff33800000, 0xffffffff34800000, 0xffffffff37800000)
the space 16384K, 9% used [0xffffffff33800000, 0xffffffff3397cb78, 0xffffffff3397cc00, 0xffffffff34800000)
Local Time = Thu Jul 15 10:12:00 2004
Elapsed Time = 0
# HotSpot Virtual Machine Error : 10
# Error ID : 4F530E43505002EF 01
# Please report this error at
# http://java.sun.com/cgi-bin/bugreport.cgi
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.4.2_05-b04 mixed mode)
# An error report file has been saved as hs_err_pid22521.log.
# Please refer to the file for further information.
Abort (core dumped)
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
FILE 1: jni01.java
import java.lang.*;
import java.util.*;
class jni01 implements Runnable {
     // static initialise block loads shared library
     // libjni01.so at startup (before executing main)
     static {
          System.loadLibrary( "jni01" );
     // declaration of native method
     public native synchronized void print(
          long p1,
          long p2,
          long p3,
          Date p4,
          Date p5,
          long p6,
          long p7,
          Date p8,
          Date p9,
          Date p10,
          Date p11,
          Date p12,
          Date p13,
          long p14,
          long p15,
          long p16,
          long p17,
          long p18,
          String p19,
          long p20,
          long p21,
          long p22,
          long p23,
          long p24,
          String p25,
          int p26,
          long p27,
          java.lang.Long p28);
     // Constant value
     public static final long C_LongNull = 0xFFFFFFFFFFFFFFFFL;
     // main method (entry point of java application)
     public static void main(String[] args) {
          jni01 ref = new jni01();
          Thread ThreadRef = new Thread( ref );
          // start GC Thread
          ThreadRef.start();
          try
               for( int i = 0; i < 1000; ++i ) {
                    ref.print(
                         0,
                         0,
                         0,
                         null,
                         null,
                         0,
                         C_LongNull,
                         null,
                         null,
                         null,
                         null,
                         null,
                         null,
                         0,
                         0,
                         0,
                         0,
                         0,
                         null,
                         0,
                         0,
                         0,
                         0,
                         0,
                         null,
                         0,
                         0,
                         null
               } // for
               // Wait for GC Thread
               ThreadRef.join();
               System.out.println( "GC Thread joined" );
          catch (java.lang.InterruptedException ex)
               System.out.println( "Main-Thread interrupted while joining!" );
     public void run()
          for ( int iCounter = 0; iCounter < 5000; ++iCounter )
               try
                    System.out.print( "Forcing GC NOW: " );
                    System.gc();
                    Thread.currentThread().sleep( 1 );
               catch (java.lang.InterruptedException ex)
                    System.out.println( "GC Thread interrupted!" );
          } // for
     } // run
FILE 2: jni01.cpp
#include <jni.h>
#include <iostream>
#include "jni01.h"
JNIEXPORT void JNICALL Java_jni01_print( JNIEnv* env, jobject jObj,
          jlong p1,
          jlong p2,
          jlong p3,
          jobject p4,
          jobject p5,
          jlong p6,
          jlong p7,
          jobject p8,
          jobject p9,
          jobject p10,
          jobject p11,
          jobject p12,
          jobject p13,
          jlong p14,
          jlong p15,
          jlong p16,
          jlong p17,
          jlong p18,
          jstring p19,
          jlong p20,
          jlong p21,
          jlong p22,
          jlong p23,
          jlong p24,
          jstring p25,
          jint p26,
          jlong p27,
          jobject p28 )
     std::cout << "Entering C++" << std::flush << std::endl;
     usleep( 100 );
     std::cout << "Leaving C++" << std::flush << std::endl;
BUILD
javac jni01.java
javah -jni jni01
g++ -o libjni01.so -shared -Wall -m64 -fPIC -D__SOLARIS__ -D_THREAD_SAFE -D_REENTRANT -I-I$JDK_HOME/include -I$JDK_HOME/include/solaris -lpthread jni01.cpp
RUN
java -verbose:gc -Xcheck:jni -Djava.library.path=. jni01
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
- changing parameter values or parameter order may help but I don't know the exact criterias.
- 32 bit works (but our application needs 64 bit)
workaround:
comments: (company - Profidata , email - martin dot schmid at profidatagroup dot com)

Answer 1

You are not supposed to allocate memory, etc., while GC is running. That's one of the things in JVMPI implementation. Looks like this may be a related scenario, although my guess would be that JNI methods should be invoked with GC disabled already, or block until GC completes if it's already running. However, if that's not the case, then basically you might be copying from a memory location that the JVM is moving around, resulting in a null pointer...
HTH,
<rsa/>