Having proceeded to a point in which I am confident that dispatching
Rexx intepreter instances on separate Java threads is stable, I turned
back to a use case from a BSF4Rexx user who tries to halt Rexx threads
from Java. In the 4.0 API version the Halt() API of the interpreter
instance is used

The problem/phenomenon I am confronted with: after terminating the JVM I
get access violations in code outside of rexx (or BSF4Rexx), e.g. a
stack-trace may look like:

    # An unexpected error has been detected by Java Runtime Environment:
    #  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x7c9204fa, pid=5604, 
    # Java VM: Java HotSpot(TM) Client VM (11.0-b16 mixed mode, sharing 
    # Problematic frame:
    # C  [ntdll.dll+0x104fa]
    # If you would like to submit a bug report, please visit:
    #   http://java.sun.com/webapps/bugreport/crash.jsp

    ---------------  T H R E A D  ---------------

    Current thread (0x02bedc00):  VMThread [stack: 0x02cd0000,0x02d20000] 

    siginfo: ExceptionCode=0xc0000005, reading address 0xfffffffd

    EAX=0x00000000, EBX=0x02d1efe0, ECX=0x00000008, EDX=0x7c38b1d8
    ESP=0x02d1eecc, EBP=0x02d1eed0, ESI=0x6dae35a4, EDI=0x002b0000
    EIP=0x7c9204fa, EFLAGS=0x00010246

    Top of Stack: (sp=0x02d1eecc)
    0x02d1eecc:   6daa34e4 02d1ef1c 7c3420d6 002b0000
    0x02d1eedc:   00000000 00000000 6daa34e4 6dae35a4
    0x02d1eeec:   02d1efe0 00000000 001a0018 7ffdbc00
    0x02d1eefc:   00000000 000910a0 02d1eee4 02d1eaf0
    0x02d1ef0c:   02d1ef48 7c34240d 7c37a368 ffffffff
    0x02d1ef1c:   02d1ef58 7c34c0b4 00000000 6daa34e4
    0x02d1ef2c:   00000003 02d1efe0 00000000 00200000
    0x02d1ef3c:   02d1efdc 02d1ef28 02d1eaf0 02d1f054

    Instructions: (pc=0x7c9204fa)
    0x7c9204ea:   47 10 a9 00 00 02 69 0f 85 db a8 03 00 8b 45 10
    0x7c9204fa:   8a 48 fd 83 c0 f8 f6 c1 01 56 0f 84 e2 a8 03 00

    Stack: [0x02cd0000,0x02d20000],  sp=0x02d1eecc,  free space=315k
    Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
    C  [ntdll.dll+0x104fa]
    C  [msvcr71.dll+0x20d6]
    C  [msvcr71.dll+0xc0b4]
    V  [jvm.dll+0x1c8ac4]

    VM_Operation (0x00a5fb38): Exit, mode: safepoint, requested by thread 

    V  [jvm.dll+0x1c8ac4]
    ---------------  P R O C E S S  ---------------
    VM_Operation (0x00a5fb38): Exit, mode: safepoint, requested by thread 
    Java Threads: ( => current thread )
      0x02c02000 JavaThread "Low Memory Detector" daemon [_thread_blocked, 
id=5972, stack(0x02eb0000,0x02f00000)]
      0x02bff000 JavaThread "CompilerThread0" daemon [_thread_blocked, id=2944, 
      0x02bfa400 JavaThread "Attach Listener" daemon [_thread_blocked, id=3100, 
      0x02bf9000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, 
id=2088, stack(0x02dc0000,0x02e10000)]
      0x02bf0c00 JavaThread "Finalizer" daemon [_thread_blocked, id=4400, 
      0x02bef400 JavaThread "Reference Handler" daemon [_thread_blocked, 
id=3076, stack(0x02d20000,0x02d70000)]
      0x002b7000 JavaThread "main" [_thread_blocked, id=5464, 
      0x02bf9000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, 
id=2088, stack(0x02dc0000,0x02e10000)]
    Other Threads:avaThread "Finalizer" daemon [_thread_blocked, id=4400, 
    =>0x02bedc00 VMThread [stack: 0x02cd0000,0x02d20000] [id=4908]ocked, 
id=3076, stack(0x02d20000,0x02d70000)]
      0x002b7000 JavaThread "main" [_thread_blocked, id=5464, 
    VM state:at safepoint (shutting down)
    Other Threads:
    VM Mutex/Monitor currently owned by a thread:  ([mutex/lock_event])
    [0x002b5e70] UNKNOWN - owner thread: 0x02bedc00
    VM state:at safepoint (shutting down)
     def new generation   total 960K, used 448K [0x22af0000, 0x22bf0000, 
      eden space 896K,  42% used [0x22af0000, 0x22b502c0, 0x22bd0000)
      from space 64K, 100% used [0x22be0000, 0x22bf0000, 0x22bf0000)
      to   space 64K,   0% used [0x22bd0000, 0x22bd0000, 0x22be0000)
     tenured generation   total 4096K, used 97K [0x22fd0000, 0x233d0000, 
       the space 4096K,   2% used [0x22fd0000, 0x22fe87d8, 0x22fe8800, 
     compacting perm gen  total 12288K, used 284K [0x26af0000, 0x276f0000, 
       the space 12288K,   2% used [0x26af0000, 0x26b372f0, 0x26b37400, 
        ro space 8192K,  67% used [0x2aaf0000, 0x2b052d98, 0x2b052e00, 
        rw space 12288K,  53% used [0x2b2f0000, 0x2b960640, 0x2b960800, 

    Dynamic libraries:
    0x00400000 - 0x00424000         E:\jdk1.6.0_11\bin\java.exe
    0x7c910000 - 0x7c9c9000         D:\WINDOWS\system32\ntdll.dll
    ... cut ...

As can be seen from the output above, rexx is not involved here anymore.

This error occurs only, if using Halt() from Rexx (for Rexx interpreter
instances that run on different Java threads), no matter whether
trapping the halt condition is taking place in Rexx programs or not.
Without using Halt() the JVM exits without errors!


Question ad Halt(): is it possible that the Rexx signalling mechanism is
interfering with Java's signal handling?

One article that I found dealing with signals in Java and hinting at
possible problems, if native code that got started from Java (as is the
case in this scenario) uses signals is at:

Is there anything I could try to do to not have the JVM crash at shutdown?


OpenSolaris 2009.06 is a cutting edge operating system for enterprises 
looking to deploy the next generation of Solaris that includes the latest 
innovations from Sun and the OpenSource community. Download a copy and 
enjoy capabilities such as Networking, Storage and Virtualization. 
Go to: http://p.sf.net/sfu/opensolaris-get
Oorexx-devel mailing list

Reply via email to