Name: md23716 Date: 08/30/2000

Symptoms:
---------
The problem occurs with both the Sun JDK1.3 Classic and Hotspot JREs. The env_id
 passed to the JVMPI Agent for the thread doing GC looks very different than the
 env_ids for all the other threads. When this env_id is passed back to the JVM v
ia the JVMPI function
GetThreadLocalStorage, the JVM traps. Either the env_id is invalid, or the GetT
hreadLocalStorage function does not handle this "special" thread correctly.

The following sample JVMPI Agent code demonstrates the problem:

#include <jvmpi.h>
#include <assert.h>
#include <stdio.h>

JVMPI_Interface* _jvmpiAgent_jvmpiInterface = 0;

JavaVM* _jvmpiAgent_jvm = 0;

static void notify_event(JVMPI_Event *event){

  JNIEnv *env_id = event->env_id;
  void * tps;
  printf("env_id=%u\n", (unsigned long)env_id);
  tps = _jvmpiAgent_jvmpiInterface->GetThreadLocalStorage(env_id);
}

/* JVMPI Initialization */
JNIEXPORT jint JNICALL JVM_OnLoad(JavaVM *vm, char *options, void *reserved){


  int res;
  _jvmpiAgent_jvm = vm; /* Tuck away the JVM pointer for future use */

  /* Resolve to the JVMPI environment */
  res = (*_jvmpiAgent_jvm)->GetEnv(_jvmpiAgent_jvm, (void **) &_jvmpiAgent_jvmpi
Interface,
                                                                        JVMPI_VE
RSION_1);
  assert(res >= 0 && _jvmpiAgent_jvmpiInterface);
  _jvmpiAgent_jvmpiInterface->NotifyEvent = notify_event;

  res = _jvmpiAgent_jvmpiInterface->EnableEvent(JVMPI_EVENT_GC_START, 0);

  res = _jvmpiAgent_jvmpiInterface->EnableEvent(JVMPI_EVENT_OBJ_FREE, 0);

  res = _jvmpiAgent_jvmpiInterface->EnableEvent(JVMPI_EVENT_OBJ_MOVE, 0);

  res = _jvmpiAgent_jvmpiInterface->EnableEvent(JVMPI_EVENT_GC_FINISH, 0);

  return JNI_OK;
}

To reproduce the problem, compile and run this agent against the Sun sample prog
ram Texture, for example:
 java.exe -Xrunenv_id_bug -cp f:\Java2D-samples\Paint Texture

Analysis :
----------
The following are the inferences of the frontline analysis:

Notes on Problem Recreation :
-----------------------------
1) The TestCase sent by the client was used to recreate the problem.

2) env_id_bug.c file is provided by the client, which has to be compiled to 'env
_id_bug.dll'

Complie the given 'c' file to a 'dll :
------------------------------------------------

On Win32, the following command builds a dynamic link library env_id_bug.dll usi
ng Microsoft Visual C++ 5.0:

     cl -Ic:\java\include -Ic:\java\include\win32 -LD env_id_bug.c -env_id_bug.d
ll

     This command further creates env_id_bug.lib file.

To recreate the problem :
-------------------------
Use the command : java -Xrunenv_id_bug -cp d:\jtcrandd\27988 Texture
        where Texture is the Sun sample program


Inference :
----------
The problem was recreated in the following environment with the help of the test
 cases provided by the client.

1) Sun JDK => JDK1.3.0-C on Win-NT SP4.
2) Sun JDK => JDK1.4.0beta-b23 Win-NT SP4.

a) When used Sun JDK => JDK1.3.0-C on Win-NT SP4.

   The output is as shown in the bmp - CrashSunjdk1.3.bmp

b) When used Sun JDK => JDK1.4.0beta-b23 Win-NT SP4.

   The output is as shown in the bmp - CrashSunjdk1.4.bmp
   There is a slight difference in this later version. The application crashes w
hen it receives any message Eg. When a mo
use is moved on the application or the application is
 minimised and maximised.

   When the cancel button is clicked it goes to the debug mode by using the VC++
5.0 tools.
   The output is captured in file debug.bmp. More probe has to be done here. i.e
. in the line " mov esi,dword ptr [eax+60h]" as indicated in th
e bmp.



Note : In Sun JDK => JDK1_2_2_005 and other lower version on Sun jdk it works fi
ne.



Behaviour differences:
----------------------
Other Java platforms, such as the IBM JDKs do not apparently use "special" threa
ds for GC and thus the GetThreadLocalStorage API functions correctly for the GC
thread.

Impact on product plans:
------------------------
There is no safe way to determine if the GetThreadLocalStorage API is safe to ca
ll for a given env_id passed to the PI Agent via the JVM. This causes us to hav
e to make the code very brittle by hardcoding the observed problematic env_id va
lues into the PI Agent to prevent the PI Agent from causing the JVM to crash.

======================================================================