Re: [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

Rony G. Flatscher Mon, 18 Aug 2025 11:09:13 -0700

Dear Dom,

thank you *very* much for your efforts and information!


On 18.08.2025 00:24, dominicjw...@gmail.com wrote:

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 inInterpreterInstance::terminate() and it looks like the patch tried out was inInterpreterInstance::detachThread. Mostly my fault as I wasn’t able to add a diff file earlierbecause all the line numbers are out in my source file due to the various printfs and other testchanges (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 areal 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 likethe 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 byinspection 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 justfor me and it might make no difference for anyone else but I’d definitely suggest trying with thechange just in InterpreterInstance::terminate()

Indeed, it seems that I placed the releaseAccess() at a different place. Now I changed the code tomatch your hand-made diff, here the "svn diff" of my actual change, which is almost identical to themanual one! :)


   D:\orx.work202312\main_trunk_20240312\trunk>svn diff
   Index: interpreter/runtime/InterpreterInstance.cpp
   ===================================================================
   --- interpreter/runtime/InterpreterInstance.cpp (revision 13006)
   +++ interpreter/runtime/InterpreterInstance.cpp (working copy)
   @@ -559,6 +559,7 @@
         commandHandlers = OREF_NULL;
         requiresFiles = OREF_NULL;

   +ActivityManager::releaseAccess();

         // tell the main interpreter controller we're gone.
         Interpreter::terminateInterpreterInstance(this);

With this change fxml_99 runs successfully, and fxml_26 does not crash anymore! However itexperiences a runtime error in not filling the TableView with the person records. fxml_27 is basedon fxml_27 and does not crash either, but experiences the same problem as fxml_26. (Also fxml_25which starts the series of TableView demonstrations ran once with a crash, but then executed withouta crash and functions.)


HTH,

---rony

P.S.: Sorry for not being too responsive at the moment, am heavily side tracked 
for the next days.

*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 callbacksfrom native code into Rexx.

Running the sample "BSF4ooRexx\samples\JavaFX\fxml_26\demoTableViewComboBoxCell.rex" now crasheswhen populating the table, making it editable and then delete a line (which causes a RexxProxy tobe 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+11java.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 thefollowing 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+20javafx.graphics@23.0.2

    j  
com.sun.javafx.application.LauncherImpl$$Lambda+0x000001f001146cf0.run()V+8javafx.graphics@23.0.2

    j  
com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(Ljava/lang/Runnable;Ljava/util/concurrent/CountDownLatch;)V+1javafx.graphics@23.0.2

    j  
com.sun.javafx.application.PlatformImpl$$Lambda+0x000001f0011434f8.run()V+8javafx.graphics@23.0.2

    j  
com.sun.javafx.application.PlatformImpl.lambda$runLater$10(Ljava/lang/Runnable;)Ljava/lang/Void;+1javafx.graphics@23.0.2

    j  
com.sun.javafx.application.PlatformImpl$$Lambda+0x000001f0011468a0.run()Ljava/lang/Object;+4javafx.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
 (69 bytes) @ 0x000001f059612444 [0x000001f0596122e0+0x0000000000000164]

    j  
java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+13java.base@23.0.2

    j  
com.sun.javafx.application.PlatformImpl.lambda$runLater$11(Ljava/lang/Runnable;Ljava/security/AccessControlContext;)V+7javafx.graphics@23.0.2

    j  
com.sun.javafx.application.PlatformImpl$$Lambda+0x000001f001146440.run()V+8javafx.graphics@23.0.2

    j  
com.sun.glass.ui.InvokeLaterDispatcher$Future.run()V+4javafx.graphics@23.0.2

    v  ~StubRoutines::call_stub 0x000001f060990fcd

    j  
com.sun.glass.ui.win.WinApplication._runLoop(Ljava/lang/Runnable;)V+0javafx.graphics@23.0.2

    j  
com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(ILjava/lang/Runnable;)V+8javafx.graphics@23.0.2

    j  
com.sun.glass.ui.win.WinApplication$$Lambda+0x000001f001134770.run()V+12javafx.graphics@23.0.2

    j  
java.lang.Thread.runWith(Ljava/lang/Object;Ljava/lang/Runnable;)V+5java.base@23.0.2

    j  java.lang.Thread.run()V+19java.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+20javafx.graphics@23.0.2

    j  
com.sun.javafx.application.LauncherImpl$$Lambda+0x000001c939146ee8.run()V+8javafx.graphics@23.0.2

    j  
com.sun.javafx.application.PlatformImpl.lambda$runAndWait$12(Ljava/lang/Runnable;Ljava/util/concurrent/CountDownLatch;)V+1javafx.graphics@23.0.2

    j  
com.sun.javafx.application.PlatformImpl$$Lambda+0x000001c939143730.run()V+8javafx.graphics@23.0.2

    j  
com.sun.javafx.application.PlatformImpl.lambda$runLater$10(Ljava/lang/Runnable;)Ljava/lang/Void;+1javafx.graphics@23.0.2

    j  
com.sun.javafx.application.PlatformImpl$$Lambda+0x000001c939146a98.run()Ljava/lang/Object;+4javafx.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
 (69 bytes) @ 0x000001c91e235a44 [0x000001c91e2358e0+0x0000000000000164]

    j  
java.security.AccessController.doPrivileged(Ljava/security/PrivilegedAction;Ljava/security/AccessControlContext;)Ljava/lang/Object;+13java.base@23.0.2

    j  
com.sun.javafx.application.PlatformImpl.lambda$runLater$11(Ljava/lang/Runnable;Ljava/security/AccessControlContext;)V+7javafx.graphics@23.0.2

    j  
com.sun.javafx.application.PlatformImpl$$Lambda+0x000001c9391461f8.run()V+8javafx.graphics@23.0.2

    j  
com.sun.glass.ui.InvokeLaterDispatcher$Future.run()V+4javafx.graphics@23.0.2

    v  ~StubRoutines::call_stub 0x000001c9255c0fcd

    j  
com.sun.glass.ui.win.WinApplication._runLoop(Ljava/lang/Runnable;)V+0javafx.graphics@23.0.2

    j  
com.sun.glass.ui.win.WinApplication.lambda$runLoop$3(ILjava/lang/Runnable;)V+8javafx.graphics@23.0.2

    j  
com.sun.glass.ui.win.WinApplication$$Lambda+0x000001c939134970.run()V+12javafx.graphics@23.0.2

    j  
java.lang.Thread.runWith(Ljava/lang/Object;Ljava/lang/Runnable;)V+5java.base@23.0.2

    j  java.lang.Thread.run()V+19java.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 nativecode 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 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<rony.flatsc...@wu.ac.at> <mailto:rony.flatsc...@wu.ac.at>

        Sent: 17 August 2025 09:30

        To: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
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [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

Reply via email to