The main thread of the application runs in a loop processing commands from the console. If the command is to run a Java agent, the JVM is invoked with JNI_CreateJavaVM() (unless it's already been started). Then, a new thread is spawned to run the command. The new thread issues an AttachCurrentThread() to obtain a valid JNIEnv pointer. When finished processing, the thread detaches itself from the JVM using DetachCurrentThread(), and the thread exits. This all works the first time through. The second time around (due to a new run command for the identical agent), the thread chokes in AttachCurrentThread (see stack below).

This same problem had existed previously, when the JVM was being started in the spawned thread the first time it was needed. The solution at that time was to make sure the JVM was started in the main thread. This worked for a while, but now the problem has returned.

Problem has been reproduced with both 1.3.1-b24 and 1.4.1 beta on Solaris 8.

Here's the stack trace with 1.3.1:


>>> 07/15/2002 17:36:22 Agent error: #
>>> 07/15/2002 17:36:22 Agent error:
>>> 07/15/2002 17:36:22 Agent error: # HotSpot Virtual Machine Error,
>>> Internal Error
>>> 07/15/2002 17:36:22 Agent error:
>>> 07/15/2002 17:36:22 Agent error: # Please report this error at
>>> 07/15/2002 17:36:22 Agent error:
>>> 07/15/2002 17:36:22 Agent error: #
>>> http://java.sun.com/cgi-bin/bugreport.cgi
>>> 07/15/2002 17:36:22 Agent error:
>>> 07/15/2002 17:36:22 Agent error: #
>>> 07/15/2002 17:36:22 Agent error:
>>> 07/15/2002 17:36:22 Agent error: # Error ID:
>>> 5448524541442C4F43414C33544F524147450E4350500042 01
>>> 07/15/2002 17:36:22 Agent error:
>>> 07/15/2002 17:36:22 Agent error: #
>>> 07/15/2002 17:36:22 Agent error:
>>> 07/15/2002 17:36:22 Agent error: # Problematic Thread:
>>>
>>>
>>> (dbx 69) where
>>> current thread: t@17
>>> [1] os::get_native_priority(0x3315e0, 0xfa99ef74, 0x0, 0xff2bb7a9,
>>> 0xfa99f840, 0xf4c283fe), at 0xf498d5a0
>>> [2] os::get_priority(0x3315e0, 0xfa99efdc, 0xf4c92000, 0xfa99f02c,
>>> 0xf4ca5134, 0xf4c92000), at 0xf498d52c
>>> [3] Thread::print(0x3315e0, 0xf4c92000, 0x70, 0xfa99e, 0xf4c92000,
>>> 0xfa99efdc), at 0xf4bb3cbc
>>> [4] report_error(0xd4, 0xfa99f86c, 0x42, 0xf4c28208, 0xf4cffddc,
>>> 0xf4c92000), at 0xf4b0f88c
>>> [5] report_fatal(0x42, 0xf4c92000, 0xf4c482a8, 0xfa9a0, 0xf4c92000,
>>> 0xfa9a019c), at 0xf4b0f1d4
>>> [6] ThreadLocalStorage::set_thread(0xf4c92000, 0x3315e0, 0x3315e0, 0x5,
>>>
>>
>>> 0x0, 0x0), at 0xf49f50a8
>>> [7] Thread::initialize_thread_local_storage(0x3315e0, 0x6, 0x3315e0,
>>> 0x30, 0x0, 0x0), at 0xf4acdaf0
>>> [8] jni_AttachCurrentThread(0xf4ca0338, 0x3315e0, 0xfa9a03d4,
>>> 0xf4c92000, 0x2c2fa4, 0xfa9a03d4), at 0xf4b43480
>>> [9] JavaSessionADT::JavaSessionADT(0x2c2fa0, 0x1f8, 0xf4ca033c,
>>>
>> 0x4eb58,
>>
>>> 0x0, 0x1e8), at 0xfb3d9094
>>> [10] JCSession::startJavaSession(0x4eb58, 0x0, 0xfeefeb98, 0xfe675ba4,
>>> 0x100, 0x23a84), at 0xfb3d2d48
>>> [11] JAVACON_MessageProc(0x1001, 0x4eb58, 0xfa9a056c, 0x0, 0x1,
>>> 0x86990), at 0xfb3d2530
>>> [12] DLLNode::SendLSXMessage(0x86a10, 0x1001, 0x4eb58, 0xfa9a056c,
>>> 0xfa9a056c, 0x39400), at 0xfe5c1fb0
>>> [13] LSISession::ProcessCallback(0x70190, 0x23, 0x2b99e8, 0xfa9a0678,
>>> 0x230000, 0xff0748a0), at 0xfe5b1cec
>>> [14] LSsInstance::XClientCallback(0x4eb58, 0x23, 0x2b99e8, 0xfa9a0678,
>>> 0x2, 0xffff0000), at 0xfe5d5fc4
>>> [15] LSsInstance::UseModule(0x4eb58, 0x2b3c7c, 0xde828, 0x4, 0xc400,
>>> 0x0), at 0xfe5d49e0
>>> [16] LSsThread::OP_USE(0x12d3d4, 0x23, 0xffff0000, 0xbc, 0xbc, 0x8000),
>>>
>>
>>> at 0xfe62c3ec
>>> [17] LSsThread::NRun(0x12d3d4, 0xfe63620c, 0xfeefd508, 0xfeeecf9f,
>>> 0xfeefd5c8, 0xfeeecfe4), at 0xfe639104
>>> [18] LSsThread::Run(0x12d3d4, 0x0, 0x12d3d4, 0x4eb58, 0x0, 0xdea80), at
>>>
>>
>>> 0xfe6393c4
>>> [19] LSsInstance::ModuleLoader(0x424f534c, 0x0, 0x0, 0x424f5000,
>>> 0xae389c6d, 0x1), at 0xfe5ceb2c
>>> [20] LSsInstance::LoadByName(0x4eb58, 0xfe5b03a8, 0x86810, 0x0, 0x0,
>>> 0x867d0), at 0xfe5ce758
>>> [21] LSIModule::LoadObject(0x86810, 0x49c64, 0x8f0, 0x0, 0x8f6,
>>> 0x57a14), at 0xfe5b0b58
>>> [22] CLSIDocument::RunScript(0x6fe10, 0x70190, 0xfedd8d2c, 0xfec8b21d,
>>> 0x0, 0x0), at 0xfe5b4914
>>> [23] CRawActionLotusScript::Run(0x70150, 0x70a10, 0xfeee7524, 0x44828,
>>> 0x0, 0x0), at 0xfe531a38
>>> [24] CRawAction::Run(0x6fbd0, 0x70a10, 0x0, 0xfa9a0dfc, 0x0, 0x0), at
>>> 0xfe5201ac
>>> [25] CRawAction::Execute(0x6fbd0, 0x70a10, 0x40, 0x10, 0x0, 0x7de10),
>>>
>> at
>>
>>> 0xfe51f6a8
>>> [26] CAssistant::RunAlone(0x7de10, 0x70a10, 0xff85, 0xfe544488, 0xff85,
>>>
>>
>>> 0x44858), at 0xfe529698
>>> [27] CAssistant::Run(0x7de10, 0xfa9a1bf0, 0x4f, 0x0, 0xfedd8d2c,
>>> 0x2c00), at 0xfe529168
>>> [28] AgentRun(0x7de10, 0x70a10, 0xfe52078c, 0x10, 0x86690, 0x0), at
>>> 0xfe543f58
>>> =>[29] ExecConsoleAgent(pArg = 0x2bb7c4), line 1737 in "ammain.cpp"
>>> [30] ThreadWrapper(Parameter = (nil)), line 1191 in "thread.c"
>>> (dbx 70)

We have tried applying the libthread patch 108827-25 (see bug 4196528). Have also tried running the with libjvm_g.so and -XX:+TraceJNICalls to determine if the threads were detaching properly, and the VM crashes on the first
run through after the thread has ended with this stack:

(dbx 9) thread t@5
t@5 (l@6) stopped in _read at 0xfcf9b3bc
0xfcf9b3bc: _read+0x0008: ta 0x8
(dbx 10) where
current thread: t@5
  [1] _read(0x0, 0xf5f80334, 0x10, 0xff26e000, 0xff275284, 0x6), at
0xfcf9b3bc
  [2] read(0x0, 0x0, 0x0, 0x0, 0x54, 0x0), at 0xff25a6c0
=>[3] fatal_error(signl = 6, info = 0xf5f80930, context = 0xf5f80678),
line 1851 in "break.c"
  [4] __sighndlr(0x6, 0xf5f80930, 0xf5f80678, 0xfd244ee8, 0xf5f81e14,
0xf5f81e04), at 0xff25b830
  [5] sigacthandler(0x6, 0xf5f81d70, 0x0, 0x0, 0x0, 0xff26e000), at
0xff258508
  ---- called from signal handler with signal 6 (SIGABRT) ------
  [6] __sigprocmask(0x0, 0xf5f80a40, 0x0, 0x0, 0x0, 0x0), at 0xff259794
  [7] _resetsig(0xff25bf6c, 0x0, 0x0, 0xf5f81d70, 0xff26e000, 0x0), at
0xff24e9a0
  [8] _sigon(0xf5f81d70, 0xff275938, 0x6, 0xf5f80b14, 0xf5f81d70, 0x0), at
0xff24e140
  [9] _thrp_kill(0x0, 0x5, 0x6, 0xff26e000, 0x5, 0x6), at 0xff251180
  [10] raise(0x6, 0x6, 0xf5f80bd8, 0xff26e000, 0x6, 0x4), at 0xfcf4b758
  [11] abort(0xfcfba000, 0xf5f80c70, 0x0, 0xfffffff8, 0x4, 0xf5f80c91), at
0xfcf35a3c
  [12] os::abort(0x1, 0xf5c38bbf, 0xf5f81514, 0xf5da1985, 0xf5da1926,
0x0), at 0xf58f7624
  [13] report_error(0x1, 0xf5d65c5a, 0x14a, 0xf5c389e5, 0xf5c389f7,
0xf5d65c52), at 0xf54a79bc
  [14] report_assertion_failure(0xf5d65c52, 0xf5d65c5a, 0x14a, 0xf5d65c97,
0x169388, 0x0), at 0xf54a
6ca0
  [15] Thread::suspend_thread_impl(0x289900, 0xf5f8176c, 0x3, 0x0, 0x0,
0x0), at 0xf5ad3b20
  [16] Thread::suspend_other(0x289900, 0x3, 0x900, 0xff27b1c8, 0x0, 0x0),
at 0xf5ad356c
  [17] ThreadSafepointState::examine_state_of_thread(0x28a4e8, 0x0, 0x0,
0xff26e000, 0xf5f81e14, 0xf
5f81e04), at 0xf5a1dd10
  [18] SafepointSynchronize::begin(0xf5f81c00, 0x169300, 0x3e8, 0x0, 0x0,
0x0), at 0xf5a1b6f4
  [19] VMThread::loop(0x245e30, 0x5, 0x0, 0x0, 0x0, 0x0), at 0xf5b7dc7c
  [20] VMThread::run(0x245e30, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xf5b7d520
  [21] _start(0x245e30, 0xff26f690, 0x1, 0x1, 0xff26e000, 0x0), at
0xf58f583c
(dbx 11)