Halt() does not use any signalling mechanisms. It only iterates through the threads associated with each instance and sets a flag indicating that a halt condition needs to be raised. That flag is detected at instruction boundaries and the condition gets raised. That's all that this does.
Rick On Thu, Jun 4, 2009 at 5:23 PM, Rony G. Flatscher <rony.flatsc...@wu-wien.ac.at> wrote: > 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, > tid=4908 > # > # Java VM: Java HotSpot(TM) Client VM (11.0-b16 mixed mode, sharing > windows-x86) > # 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] > [id=4908] > > siginfo: ExceptionCode=0xc0000005, reading address 0xfffffffd > > Registers: > 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 > code) > 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 > 0x002b7000 > > V [jvm.dll+0x1c8ac4] > --------------- P R O C E S S --------------- > VM_Operation (0x00a5fb38): Exit, mode: safepoint, requested by thread > 0x002b7000 > 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, > stack(0x02e60000,0x02eb0000)] > 0x02bfa400 JavaThread "Attach Listener" daemon [_thread_blocked, id=3100, > stack(0x02e10000,0x02e60000)] > 0x02bf9000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, > id=2088, stack(0x02dc0000,0x02e10000)] > 0x02bf0c00 JavaThread "Finalizer" daemon [_thread_blocked, id=4400, > stack(0x02d70000,0x02dc0000)]02f00000)] > 0x02bef400 JavaThread "Reference Handler" daemon [_thread_blocked, > id=3076, stack(0x02d20000,0x02d70000)] > 0x002b7000 JavaThread "main" [_thread_blocked, id=5464, > stack(0x00a10000,0x00a60000)]10000,0x02e60000)] > 0x02bf9000 JavaThread "Signal Dispatcher" daemon [_thread_blocked, > id=2088, stack(0x02dc0000,0x02e10000)] > Other Threads:avaThread "Finalizer" daemon [_thread_blocked, id=4400, > stack(0x02d70000,0x02dc0000)] > =>0x02bedc00 VMThread [stack: 0x02cd0000,0x02d20000] [id=4908]ocked, > id=3076, stack(0x02d20000,0x02d70000)] > 0x002b7000 JavaThread "main" [_thread_blocked, id=5464, > stack(0x00a10000,0x00a60000)] > 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) > Heap > def new generation total 960K, used 448K [0x22af0000, 0x22bf0000, > 0x22fd0000) > 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, > 0x26af0000) > the space 4096K, 2% used [0x22fd0000, 0x22fe87d8, 0x22fe8800, > 0x233d0000) > compacting perm gen total 12288K, used 284K [0x26af0000, 0x276f0000, > 0x2aaf0000) > the space 12288K, 2% used [0x26af0000, 0x26b372f0, 0x26b37400, > 0x276f0000) > ro space 8192K, 67% used [0x2aaf0000, 0x2b052d98, 0x2b052e00, > 0x2b2f0000) > rw space 12288K, 53% used [0x2b2f0000, 0x2b960640, 0x2b960800, > 0x2bef0000) > > 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: > <http://www.ibm.com/developerworks/java/library/i-signalhandling/>. > > Is there anything I could try to do to not have the JVM crash at shutdown? > > ---rony > > > > ------------------------------------------------------------------------------ > 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 > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > > ------------------------------------------------------------------------------ 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 Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
