Hi everyone,
Sorry but I’ve been away for a bit and can see everything has got quite lively in my absence! There may have been a misunderstanding but the change I made was in InterpreterInstance::terminate() and it looks like the patch tried out was in InterpreterInstance::detachThread. Mostly my fault as I wasn’t able to add a diff file earlier because all the line numbers are out in my source file due to the various printfs and other test changes (all commented out apart from the actual one-line change) currently present in my version. This was never meant to be a proper fix by the way but a pointer to the general direction of a real one for those more knowledgeable with the code 😊 Anyway looking at the very recent SVN version I was working from, a diff file would be more like the following. Note the start line is 559 which is near the very end of InterpreterInstance::terminate(). Please don’t try to “apply” it as I’ve constructed it by inspection but hopefully its readable enough to make it clear what I’ve changed. +++ interpreter/runtime/InterpreterInstance.cpp (working copy) @@ -559,8 +559,9 @@ commandHandlers = OREF_NULL; requiresFiles = OREF_NULL; + ActivityManager::releaseAccess(); // tell the main interpreter controller we're gone. Interpreter::terminateInterpreterInstance(this); return true; } I should mention that on my machine I don’t get crashes running with the patch in either location (i.e. including the one which crashes for Rony) so there might be some magic working just for me and it might make no difference for anyone else but I’d definitely suggest trying with the change just in InterpreterInstance::terminate() Kind Regards, Dom From: Rony G. Flatscher <rony.flatsc...@wu.ac.at> Sent: 17 August 2025 21:40 To: oorexx-devel@lists.sourceforge.net Subject: [Oorexx-devel] Hack causes new crashes when calling back from native code into ooRexx, hence backing out ... (Re: Some more information, and a random run (Re: Question ad a hang situation Well, although the testsuite ran successfully on my system there are now new crashes for callbacks from native code into Rexx. Running the sample "BSF4ooRexx\samples\JavaFX\fxml_26\demoTableViewComboBoxCell.rex" now crashes when populating the table, making it editable and then delete a line (which causes a RexxProxy to be garbage collected, freeing the contained Rexx peer object). Here the Java 17 hs_err_pid29420.log (full log attached): # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ff996433d68, pid=29420, tid=35512 # # JRE version: OpenJDK Runtime Environment (17.0.6+10) (build 17.0.6+10-LTS) # Java VM: OpenJDK 64-Bit Server VM (17.0.6+10-LTS, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64) # Problematic frame: # C [rexx.dll+0x133d68] Activity::checkStackSpace+0x28 # # No core dump will be written. Minidumps are not enabled by default on client versions of Windows # # If you would like to submit a bug report, please visit: # https://bell-sw.com/support # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- S U M M A R Y ------------ Command Line: Host: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 8 cores, 23G, Windows 10 , 64 bit Build 19041 (10.0.19041.5915) Time: Sun Aug 17 21:31:28 2025 W. Europe Daylight Time elapsed time: 17.545102 seconds (0d 0h 0m 17s) --------------- T H R E A D --------------- Current thread (0x000001f0b06f8760): JavaThread "RexxCleanupRef.runnableCleaner_1" [_thread_in_native, id=35512, stack(0x0000007bf4200000,0x0000007bf4a00000)] Stack: [0x0000007bf4200000,0x0000007bf4a00000], sp=0x0000007bf49feb60, free space=8186k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rexx.dll+0x133d68] Activity::checkStackSpace+0x28 (activity.cpp:2265) C [rexx.dll+0x60fcc] RexxObject::messageSend+0x3c (objectclass.cpp:871) C [rexx.dll+0x154d53] ExpressionStack::send+0x73 (expressionstack.hpp:80) C [rexx.dll+0x1544ae] RexxExpressionMessage::evaluate+0x17e (expressionmessage.cpp:191) C [rexx.dll+0x154398] RexxExpressionMessage::evaluate+0x68 (expressionmessage.cpp:158) C [rexx.dll+0x154398] RexxExpressionMessage::evaluate+0x68 (expressionmessage.cpp:158) C [rexx.dll+0x15b0f1] RexxInstructionAssignment::execute+0xd1 (assignmentinstruction.cpp:129) C [rexx.dll+0xd1ad2] RexxActivation::run+0x632 (rexxactivation.cpp:618) C [rexx.dll+0xe53a7] RexxCode::run+0x97 (rexxcode.cpp:211) C [rexx.dll+0x42d62] MethodClass::run+0x82 (methodclass.cpp:172) C [rexx.dll+0x61126] RexxObject::messageSend+0x196 (objectclass.cpp:901) C [rexx.dll+0x333f7] RexxObject::sendMessage+0x47 (objectclass.hpp:509) C [rexx.dll+0x5f229] RexxObject::uninit+0x69 (objectclass.cpp:2584) C [rexx.dll+0x109796] UninitDispatcher::run+0x36 (uninitdispatcher.cpp:55) C [rexx.dll+0xe927d] NativeActivation::run+0x9d (nativeactivation.cpp:1743) C [rexx.dll+0x13687c] Activity::run+0x5c (activity.cpp:3452) C [rexx.dll+0x1188d9] MemoryObject::runUninits+0x129 (rexxmemory.cpp:373) C [rexx.dll+0xdf3d4] MemoryObject::checkUninitQueue+0x34 (rexxmemory.hpp:123) C [rexx.dll+0x136665] Activity::exitCurrentThread+0x45 (activity.cpp:325) C [rexx.dll+0xa3efc] ApiContext::~ApiContext+0x6c (contextapi.hpp:267) C [rexx.dll+0xab16c] NewStringFromAsciiz+0x7c (threadcontextstubs.cpp:1100) C [BSF4ooRexx850.DLL+0xdd4a] C 0x000001f0973fd621 Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j org.rexxla.bsf.engines.rexx.RexxCleanupRef.jniUnregisterRexxObject(Ljava/lang/String;)I+0 j org.rexxla.bsf.engines.rexx.RexxCleanupRef.finalizeRexxObject()V+115 j org.rexxla.bsf.engines.rexx.RexxCleanupRef.access$100(Lorg/rexxla/bsf/engines/rexx/RexxCleanupRef;)V+1 j org.rexxla.bsf.engines.rexx.RexxCleanupRef$1.run()V+17 j java.lang.Thread.run()V+11 java.base@17.0.6 <mailto:java.base@17.0.6> v ~StubRoutines::call_stub siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x0000000000000100 Register to memory mapping: RIP=0x00007ff996433d68 rexx.dll::Activity::checkStackSpace + 0x28 RAX=0x0000007bf49feb80 is pointing into the stack for thread: 0x000001f0b06f8760 RBX=0x0000007bf49ff5c0 is pointing into the stack for thread: 0x000001f0b06f8760 RCX=0x0 is NULL RDX=0x000001f0860151f0 points into unknown readable memory: 0x00007ff99661ef20 | 20 ef 61 96 f9 7f 00 00 RSP=0x0000007bf49feb60 is pointing into the stack for thread: 0x000001f0b06f8760 RBP=0x000001f0b06f8a08 points into unknown readable memory: 0x00007ff976809f30 | 30 9f 80 76 f9 7f 00 00 RSI=0x000001f083ea5ba0 points into unknown readable memory: 0x303635323331322d | 2d 32 31 33 32 35 36 30 RDI=0x0000007bf49feb90 is pointing into the stack for thread: 0x000001f0b06f8760 R8 =0x000001f086be2ba8 points into unknown readable memory: 0x000001f085cd0620 | 20 06 cd 85 f0 01 00 00 R9 =0x0 is NULL R10=0x00007ff996636608 rexx.dll::`string' + 0x0 R11=0x000001f085f7ddc0 points into unknown readable memory: 0x000001f085fabb30 | 30 bb fa 85 f0 01 00 00 R12=0x0 is NULL R13={method} {0x000001f0b0c3f7e8} 'jniUnregisterRexxObject' '(Ljava/lang/String;)I' in 'org/rexxla/bsf/engines/rexx/RexxCleanupRef' R14=0x0000007bf49ff5c8 is pointing into the stack for thread: 0x000001f0b06f8760 R15=0x000001f0b06f8760 is a thread ... cut ... (see attached hs_err_pid29420.log) -------------- Activating "::options trace r" with .traceObject~option="F" and running on Java 23 causes the following crash (hs_err_pid18472.log enclosed): # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ff995f13d68, pid=18472, tid=33888 # # JRE version: OpenJDK Runtime Environment (23.0.2+9) (build 23.0.2+9) # Java VM: OpenJDK 64-Bit Server VM (23.0.2+9, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64) # Problematic frame: # C [rexx.dll+0x133d68] Activity::checkStackSpace+0x28 # # No core dump will be written. Minidumps are not enabled by default on client versions of Windows # # If you would like to submit a bug report, please visit: # https://bell-sw.com/support # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- S U M M A R Y ------------ Command Line: Host: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 8 cores, 23G, Windows 10 , 64 bit Build 19041 (10.0.19041.5915) Time: Sun Aug 17 21:53:01 2025 W. Europe Daylight Time elapsed time: 2.868394 seconds (0d 0h 0m 2s) --------------- T H R E A D --------------- Current thread (0x000001f077948800): JavaThread "JavaFX Application Thread" [_thread_in_native, id=33888, stack(0x000000ee2fe00000,0x000000ee30600000) (8192K)] Stack: [0x000000ee2fe00000,0x000000ee30600000], sp=0x000000ee305fd1c0, free space=8180k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rexx.dll+0x133d68] Activity::checkStackSpace+0x28 (activity.cpp:2265) C [rexx.dll+0x60fcc] RexxObject::messageSend+0x3c (objectclass.cpp:871) C [rexx.dll+0x333f7] RexxObject::sendMessage+0x47 (objectclass.hpp:509) C [rexx.dll+0x5f5fe] RexxObject::stringValue+0x4e (objectclass.cpp:1160) C [rexx.dll+0xd59b4] RexxActivation::traceValue+0x74 (rexxactivation.cpp:3710) C [rexx.dll+0x154f19] RexxActivation::traceResult+0x49 (rexxactivation.hpp:369) C [rexx.dll+0x17985a] RexxInstructionExpression::evaluateExpression+0x6a (rexxinstruction.cpp:231) C [rexx.dll+0x1792cb] RexxInstructionReturn::execute+0x4b (returninstruction.cpp:72) C [rexx.dll+0xd1ad2] RexxActivation::run+0x632 (rexxactivation.cpp:618) C [rexx.dll+0xe547b] RexxCode::call+0xbb (rexxcode.cpp:188) C [rexx.dll+0x71e70] RoutineClass::call+0xa0 (routineclass.cpp:194) C [rexx.dll+0xd44c7] RexxActivation::externalCall+0xb7 (rexxactivation.cpp:3047) C [rexx.dll+0x153a27] RexxExpressionFunction::evaluate+0x247 (expressionfunction.cpp:214) C [rexx.dll+0x15b08a] RexxInstructionAssignment::execute+0x6a (assignmentinstruction.cpp:118) C [rexx.dll+0xd1ad2] RexxActivation::run+0x632 (rexxactivation.cpp:618) C [rexx.dll+0xe53a7] RexxCode::run+0x97 (rexxcode.cpp:211) C [rexx.dll+0x42d62] MethodClass::run+0x82 (methodclass.cpp:172) C [rexx.dll+0x61126] RexxObject::messageSend+0x196 (objectclass.cpp:901) C [rexx.dll+0x33460] RexxObject::sendMessage+0x50 (objectclass.hpp:510) C [rexx.dll+0x3068d] RexxClass::completeNewObject+0xbd (classclass.cpp:1899) C [rexx.dll+0x5ed94] RexxObject::newRexx+0xc4 (objectclass.cpp:2644) C [rexx.dll+0xcce61] CPPCode::run+0xe1 (cppcode.cpp:147) C [rexx.dll+0x42d62] MethodClass::run+0x82 (methodclass.cpp:172) C [rexx.dll+0x61126] RexxObject::messageSend+0x196 (objectclass.cpp:901) C [rexx.dll+0x154d53] ExpressionStack::send+0x73 (expressionstack.hpp:80) C [rexx.dll+0x173a77] RexxInstructionMessage::execute+0x197 (messageinstruction.cpp:189) C [rexx.dll+0xd1ad2] RexxActivation::run+0x632 (rexxactivation.cpp:618) C [rexx.dll+0xe53a7] RexxCode::run+0x97 (rexxcode.cpp:211) C [rexx.dll+0x42d62] MethodClass::run+0x82 (methodclass.cpp:172) C [rexx.dll+0x61126] RexxObject::messageSend+0x196 (objectclass.cpp:901) C [rexx.dll+0x6179a] RexxObject::sendMessage+0x6a (objectclass.cpp:748) C [rexx.dll+0xa778d] SendMessageArray+0xcd (threadcontextstubs.cpp:167) C [BSF4ooRexx850.DLL+0xd992] (no source info available) C 0x000001f06099d207 (no source info available) The last pc belongs to native method entry point (kind = native) (printed below). Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j org.rexxla.bsf.engines.rexx.RexxAndJava.jniRexxSendMessageToRexxObject(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/Object;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/Object;+0 j org.rexxla.bsf.engines.rexx.RexxEngine.call(Lorg/rexxla/bsf/engines/rexx/RexxProxy;Ljava/lang/Object;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/Object;+590 j org.rexxla.bsf.engines.rexx.RexxProxy.invoke(Ljava/lang/Object;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/Object;+123 j org.rexxla.bsf.engines.rexx.onTheFly.Application_$RexxExtendClass$_6B40AC3E.start(Ljavafx/stage/Stage;)V+38 j com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(Ljava/util/concurrent/atomic/AtomicBoolean;Ljavafx/application/Application;)V+20 javafx.graphics@23.0.2 <mailto:javafx.graphics@23.0.2> j com.sun.javafx.application.LauncherImpl$$Lambda+0x000001f001146cf0.run()V+8 javafx.graphics@23.0.2 <mailto:javafx.graphics@23.0.2> j com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(Ljava/lang/Runnable;Ljava/util/concurrent/CountDownLatch;)V+1 javafx.graphics@23.0.2 <mailto:javafx.graphics@23.0.2> j com.sun.javafx.application.PlatformImpl$$Lambda+0x000001f0011434f8.run()V+8 javafx.graphics@23.0.2 <mailto:javafx.graphics@23.0.2> j com.sun.javafx.application.PlatformImpl.lambda$runLater$10(Ljava/lang/Runnable;)Ljava/lang/Void;+1 javafx.graphics@23.0.2 <mailto:javafx.graphics@23.0.2> j com.sun.javafx.application.PlatformImpl$$Lambda+0x000001f0011468a0.run()Ljava/lang/Object;+4 javafx.graphics@23.0.2 <mailto:javafx.graphics@23.0.2> J 1258 c1 java.security.AccessController.executePrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/lang/Class;)Ljava/lang/Object; java.base@23.0.2 <mailto:java.base@23.0.2> (69 bytes) @ 0x000001f059612444 [0x000001f0596122e0+0x0000000000000164] j java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+13 java.base@23.0.2 <mailto:java.base@23.0.2> j com.sun.javafx.application.PlatformImpl.lambda$runLater$11(Ljava/lang/Runnable;Ljava/security/AccessControlContext;)V+7 javafx.graphics@23.0.2 <mailto:javafx.graphics@23.0.2> j com.sun.javafx.application.PlatformImpl$$Lambda+0x000001f001146440.run()V+8 javafx.graphics@23.0.2 <mailto:javafx.graphics@23.0.2> j com.sun.glass.ui.InvokeLaterDispatcher$Future.run()V+4 javafx.graphics@23.0.2 <mailto:javafx.graphics@23.0.2> v ~StubRoutines::call_stub 0x000001f060990fcd j com.sun.glass.ui.win.WinApplication._runLoop(Ljava/lang/Runnable;)V+0 javafx.graphics@23.0.2 <mailto:javafx.graphics@23.0.2> j com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(ILjava/lang/Runnable;)V+8 javafx.graphics@23.0.2 <mailto:javafx.graphics@23.0.2> j com.sun.glass.ui.win.WinApplication$$Lambda+0x000001f001134770.run()V+12 javafx.graphics@23.0.2 <mailto:javafx.graphics@23.0.2> j java.lang.Thread.runWith(Ljava/lang/Object;Ljava/lang/Runnable;)V+5 java.base@23.0.2 <mailto:java.base@23.0.2> j java.lang.Thread.run()V+19 java.base@23.0.2 <mailto:java.base@23.0.2> v ~StubRoutines::call_stub 0x000001f060990fcd siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x0000000000000100 Registers: RAX=0x000000ee305fd1e0, RBX=0x0000000000000000, RCX=0x0000000000000000, RDX=0x000001f04d8db8f0 RSP=0x000000ee305fd1c0, RBP=0x000001f077948bc0, RSI=0x000001f04ec86870, RDI=0x000000ee305fd1f0 R8 =0x0000000000000000, R9 =0x0000000000000000, R10=0x0000000000000000, R11=0x0000000000000246 R12=0x0000000000000000, R13=0x000001f04e3e7050, R14=0x000001f04e40d3b0, R15=0x000001f077948800 RIP=0x00007ff995f13d68, EFLAGS=0x0000000000010206 .... cut ... (see hs_err_pid18472.log) ---- And another run on Java 23 with tracing enabled and a crash: # # A fatal error has been detected by the Java Runtime Environment: # # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x00007ff995f13d68, pid=8976, tid=36040 # # JRE version: OpenJDK Runtime Environment (23.0.2+9) (build 23.0.2+9) # Java VM: OpenJDK 64-Bit Server VM (23.0.2+9, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, windows-amd64) # Problematic frame: # C [rexx.dll+0x133d68] Activity::checkStackSpace+0x28 # # No core dump will be written. Minidumps are not enabled by default on client versions of Windows # # If you would like to submit a bug report, please visit: # https://bell-sw.com/support # The crash happened outside the Java Virtual Machine in native code. # See problematic frame for where to report the bug. # --------------- S U M M A R Y ------------ Command Line: Host: Intel(R) Core(TM) i7-8550U CPU @ 1.80GHz, 8 cores, 23G, Windows 10 , 64 bit Build 19041 (10.0.19041.5915) Time: Sun Aug 17 22:05:17 2025 W. Europe Daylight Time elapsed time: 2.553712 seconds (0d 0h 0m 2s) --------------- T H R E A D --------------- Current thread (0x000001c97dc2f990): JavaThread "JavaFX Application Thread" [_thread_in_native, id=36040, stack(0x0000006c49800000,0x0000006c4a000000) (8192K)] Stack: [0x0000006c49800000,0x0000006c4a000000], sp=0x0000006c49ffbed0, free space=8175k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [rexx.dll+0x133d68] Activity::checkStackSpace+0x28 (activity.cpp:2265) C [rexx.dll+0x60fcc] RexxObject::messageSend+0x3c (objectclass.cpp:871) C [rexx.dll+0x154d53] ExpressionStack::send+0x73 (expressionstack.hpp:80) C [rexx.dll+0x1544ae] RexxExpressionMessage::evaluate+0x17e (expressionmessage.cpp:191) C [rexx.dll+0x172779] RexxInstructionIf::execute+0x59 (ifinstruction.cpp:139) C [rexx.dll+0xd1ad2] RexxActivation::run+0x632 (rexxactivation.cpp:618) C [rexx.dll+0xe53a7] RexxCode::run+0x97 (rexxcode.cpp:211) C [rexx.dll+0x42d62] MethodClass::run+0x82 (methodclass.cpp:172) C [rexx.dll+0x61126] RexxObject::messageSend+0x196 (objectclass.cpp:901) C [rexx.dll+0x154d53] ExpressionStack::send+0x73 (expressionstack.hpp:80) C [rexx.dll+0x173a77] RexxInstructionMessage::execute+0x197 (messageinstruction.cpp:189) C [rexx.dll+0xd1ad2] RexxActivation::run+0x632 (rexxactivation.cpp:618) C [rexx.dll+0xe53a7] RexxCode::run+0x97 (rexxcode.cpp:211) C [rexx.dll+0x42d62] MethodClass::run+0x82 (methodclass.cpp:172) C [rexx.dll+0x61126] RexxObject::messageSend+0x196 (objectclass.cpp:901) C [rexx.dll+0x33460] RexxObject::sendMessage+0x50 (objectclass.hpp:510) C [rexx.dll+0x3068d] RexxClass::completeNewObject+0xbd (classclass.cpp:1899) C [rexx.dll+0x5ed94] RexxObject::newRexx+0xc4 (objectclass.cpp:2644) C [rexx.dll+0xcce61] CPPCode::run+0xe1 (cppcode.cpp:147) C [rexx.dll+0x42d62] MethodClass::run+0x82 (methodclass.cpp:172) C [rexx.dll+0x61126] RexxObject::messageSend+0x196 (objectclass.cpp:901) C [rexx.dll+0x154d53] ExpressionStack::send+0x73 (expressionstack.hpp:80) C [rexx.dll+0x1544ae] RexxExpressionMessage::evaluate+0x17e (expressionmessage.cpp:191) C [rexx.dll+0x15b0f1] RexxInstructionAssignment::execute+0xd1 (assignmentinstruction.cpp:129) C [rexx.dll+0xd1ad2] RexxActivation::run+0x632 (rexxactivation.cpp:618) C [rexx.dll+0xe53a7] RexxCode::run+0x97 (rexxcode.cpp:211) C [rexx.dll+0x42d62] MethodClass::run+0x82 (methodclass.cpp:172) C [rexx.dll+0x61126] RexxObject::messageSend+0x196 (objectclass.cpp:901) C [rexx.dll+0xdab0e] RexxActivation::createTraceObject+0x6e (rexxactivation.cpp:5146) C [rexx.dll+0xdb2ee] RexxActivation::processTraceInfo+0x9e (rexxactivation.cpp:5229) C [rexx.dll+0xd5b0e] RexxActivation::traceValue+0x1ce (rexxactivation.cpp:3720) C [rexx.dll+0x154f19] RexxActivation::traceResult+0x49 (rexxactivation.hpp:369) C [rexx.dll+0x17985a] RexxInstructionExpression::evaluateExpression+0x6a (rexxinstruction.cpp:231) C [rexx.dll+0x1792cb] RexxInstructionReturn::execute+0x4b (returninstruction.cpp:72) C [rexx.dll+0xd1ad2] RexxActivation::run+0x632 (rexxactivation.cpp:618) C [rexx.dll+0xe547b] RexxCode::call+0xbb (rexxcode.cpp:188) C [rexx.dll+0x71e70] RoutineClass::call+0xa0 (routineclass.cpp:194) C [rexx.dll+0xd44c7] RexxActivation::externalCall+0xb7 (rexxactivation.cpp:3047) C [rexx.dll+0x153a27] RexxExpressionFunction::evaluate+0x247 (expressionfunction.cpp:214) C [rexx.dll+0x15b08a] RexxInstructionAssignment::execute+0x6a (assignmentinstruction.cpp:118) C [rexx.dll+0xd1ad2] RexxActivation::run+0x632 (rexxactivation.cpp:618) C [rexx.dll+0xe53a7] RexxCode::run+0x97 (rexxcode.cpp:211) C [rexx.dll+0x42d62] MethodClass::run+0x82 (methodclass.cpp:172) C [rexx.dll+0x61126] RexxObject::messageSend+0x196 (objectclass.cpp:901) C [rexx.dll+0x33460] RexxObject::sendMessage+0x50 (objectclass.hpp:510) C [rexx.dll+0x3068d] RexxClass::completeNewObject+0xbd (classclass.cpp:1899) C [rexx.dll+0x5ed94] RexxObject::newRexx+0xc4 (objectclass.cpp:2644) C [rexx.dll+0xcce61] CPPCode::run+0xe1 (cppcode.cpp:147) C [rexx.dll+0x42d62] MethodClass::run+0x82 (methodclass.cpp:172) C [rexx.dll+0x61126] RexxObject::messageSend+0x196 (objectclass.cpp:901) C [rexx.dll+0x154d53] ExpressionStack::send+0x73 (expressionstack.hpp:80) C [rexx.dll+0x173a77] RexxInstructionMessage::execute+0x197 (messageinstruction.cpp:189) C [rexx.dll+0xd1ad2] RexxActivation::run+0x632 (rexxactivation.cpp:618) C [rexx.dll+0xe53a7] RexxCode::run+0x97 (rexxcode.cpp:211) C [rexx.dll+0x42d62] MethodClass::run+0x82 (methodclass.cpp:172) C [rexx.dll+0x61126] RexxObject::messageSend+0x196 (objectclass.cpp:901) C [rexx.dll+0x6179a] RexxObject::sendMessage+0x6a (objectclass.cpp:748) C [rexx.dll+0xa778d] SendMessageArray+0xcd (threadcontextstubs.cpp:167) C [BSF4ooRexx850.DLL+0x1e468] RexxThreadContext_::SendMessageA+0x38 (oorexxapi.h:879) C [BSF4ooRexx850.DLL+0xabc6] Java_org_rexxla_bsf_engines_rexx_RexxAndJava_jniRexxSendMessageToRexxObject+0xaf6 (bsf4oorexx.cc:10543) C 0x000001c9255cd207 (no source info available) The last pc belongs to native method entry point (kind = native) (printed below). Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) j org.rexxla.bsf.engines.rexx.RexxAndJava.jniRexxSendMessageToRexxObject(Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/Object;Ljava/lang/String;Ljava/lang/String;)Ljava/lang/Object;+0 j org.rexxla.bsf.engines.rexx.RexxEngine.call(Lorg/rexxla/bsf/engines/rexx/RexxProxy;Ljava/lang/Object;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/Object;+590 j org.rexxla.bsf.engines.rexx.RexxProxy.invoke(Ljava/lang/Object;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/Object;+123 j org.rexxla.bsf.engines.rexx.onTheFly.Application_$RexxExtendClass$_6B40AC3E.start(Ljavafx/stage/Stage;)V+38 j com.sun.javafx.application.LauncherImpl.lambda$launchApplication1$9(Ljava/util/concurrent/atomic/AtomicBoolean;Ljavafx/application/Application;)V+20 javafx.graphics@23.0.2 <mailto:javafx.graphics@23.0.2> j com.sun.javafx.application.LauncherImpl$$Lambda+0x000001c939146ee8.run()V+8 javafx.graphics@23.0.2 <mailto:javafx.graphics@23.0.2> j com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(Ljava/lang/Runnable;Ljava/util/concurrent/CountDownLatch;)V+1 javafx.graphics@23.0.2 <mailto:javafx.graphics@23.0.2> j com.sun.javafx.application.PlatformImpl$$Lambda+0x000001c939143730.run()V+8 javafx.graphics@23.0.2 <mailto:javafx.graphics@23.0.2> j com.sun.javafx.application.PlatformImpl.lambda$runLater$10(Ljava/lang/Runnable;)Ljava/lang/Void;+1 javafx.graphics@23.0.2 <mailto:javafx.graphics@23.0.2> j com.sun.javafx.application.PlatformImpl$$Lambda+0x000001c939146a98.run()Ljava/lang/Object;+4 javafx.graphics@23.0.2 <mailto:javafx.graphics@23.0.2> J 1231 c1 java.security.AccessController.executePrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;Ljava/lang/Class;)Ljava/lang/Object; java.base@23.0.2 <mailto:java.base@23.0.2> (69 bytes) @ 0x000001c91e235a44 [0x000001c91e2358e0+0x0000000000000164] j java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+13 java.base@23.0.2 <mailto:java.base@23.0.2> j com.sun.javafx.application.PlatformImpl.lambda$runLater$11(Ljava/lang/Runnable;Ljava/security/AccessControlContext;)V+7 javafx.graphics@23.0.2 <mailto:javafx.graphics@23.0.2> j com.sun.javafx.application.PlatformImpl$$Lambda+0x000001c9391461f8.run()V+8 javafx.graphics@23.0.2 <mailto:javafx.graphics@23.0.2> j com.sun.glass.ui.InvokeLaterDispatcher$Future.run()V+4 javafx.graphics@23.0.2 <mailto:javafx.graphics@23.0.2> v ~StubRoutines::call_stub 0x000001c9255c0fcd j com.sun.glass.ui.win.WinApplication._runLoop(Ljava/lang/Runnable;)V+0 javafx.graphics@23.0.2 <mailto:javafx.graphics@23.0.2> j com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(ILjava/lang/Runnable;)V+8 javafx.graphics@23.0.2 <mailto:javafx.graphics@23.0.2> j com.sun.glass.ui.win.WinApplication$$Lambda+0x000001c939134970.run()V+12 javafx.graphics@23.0.2 <mailto:javafx.graphics@23.0.2> j java.lang.Thread.runWith(Ljava/lang/Object;Ljava/lang/Runnable;)V+5 java.base@23.0.2 <mailto:java.base@23.0.2> j java.lang.Thread.run()V+19 java.base@23.0.2 <mailto:java.base@23.0.2> v ~StubRoutines::call_stub 0x000001c9255c0fcd siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address 0x0000000000000100 ... cut ... (see enclosed hs_err_pid8976.log) --- So it looks like the hack may fix the hang but may cause crashes in other use-cases where native code calls into ooRexx (which may have been expected). Will therefore back out the hack from trunk. We need a real fix. ---rony On 17.08.2025 21:12, Rony G. Flatscher wrote: Dear Dom, On 17.08.2025 17:31, dominicjw...@gmail.com <mailto:dominicjw...@gmail.com> wrote: I am one such masochist that Rony was referring to 😊 Very glad that you are one! ;) It seems that in InterpreterInstance::terminate() there can be situations where the kernel lock ends up being taken twice. It is only ever released once and this means that when it has been locked twice the thread leaves the function owning the kernel lock and can go on happily locking and releasing it but any other thread trying to access it is immediately and forever locked. I spent quite some time trying to figure out and code for the individual cases (I think there may be at least two) to ensure the acquires and releases are always balanced but in the end I gave up and as a hack added an extra call to ActivityManager::releaseAccess() at the end of this function. This seems to have done the trick and the program runs ok with this in place. This is *great*, thank you very much! Could you briefly describe the two individual cases, if you have them still handy? The reasons for the additional kernel locks may be easy to identify or they may a symptom of problems elsewhere that could be very subtle or nasty but hopefully this provides a starting point Given that your hack removes the hang, and given that the testsuite runs to completion on my Windows machine, I would like to apply that hack to trunk to see, how it does on all Jenkin hosted operating systems. Here the patch I have been using and testing (yes it fixes the hang, *very* appreciated!!): Index: interpreter/runtime/InterpreterInstance.cpp =================================================================== --- interpreter/runtime/InterpreterInstance.cpp (revision 13004) +++ interpreter/runtime/InterpreterInstance.cpp (working copy) @@ -299,6 +299,7 @@ { terminationSem.post(); } + ActivityManager::releaseAccess(); // hack kudos to Dom Wise (20250817 e-mail on developer list), remove kernel lock again return true; } Of course, once a fix can be found, this patch should be replaced. First I will create an entry in the bug tracker and then commit that patch and record it against the bug. Dom, again *many* thanks for your efforts and sharing your findings, *very* much appreciated! Best regards ---rony -----Original Message----- From: Rony G. Flatscher <mailto:rony.flatsc...@wu.ac.at> <rony.flatsc...@wu.ac.at> Sent: 17 August 2025 09:30 To: oorexx-devel@lists.sourceforge.net <mailto:oorexx-devel@lists.sourceforge.net> Subject: Re: [Oorexx-devel] Some more information, and a random run (Re: Question ad a hang situation Hi Michael, On 17.08.2025 03:47, Michael Lueck wrote: W O W ! ! ! Bravo!!! A most impressive success milestone! but not solved yet. It looks as it is somehow linked to terminating interpreter instances right before the callback from Java into ooRexx. The change I made was a debug output statement from the Java garbage collector run (collecting the peer Java RexxEngines) right before the ooRexx instance gets terminated from the Java side, as if this little time span makes the difference (at least on my machine) and allows the Java callback into ooRexx to not block. ---rony _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net <mailto:Oorexx-devel@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/oorexx-devel -- -- __________________________________________________________________________________ Prof. Dr. Rony G. Flatscher, iR Department Wirtschaftsinformatik und Operations Management WU Wien Welthandelsplatz 1 A-1020 Wien/Vienna, Austria/Europe http://www.wu.ac.at __________________________________________________________________________________
_______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
