*From:*Rony G. Flatscher <rony.flatsc...@wu.ac.at>
*Sent:* 18 August 2025 19:09
*To:* oorexx-devel@lists.sourceforge.net
*Subject:* 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
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 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()
Indeed, it seems that I placed the releaseAccess() at a different place. Now I changed the code to
match your hand-made diff, here the "svn diff" of my actual change, which is almost identical to
the manual 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 it
experiences a runtime error in not filling the TableView with the person records. fxml_27 is based
on fxml_27 and does not crash either, but experiences the same problem as fxml_26. (Also fxml_25
which starts the series of TableView demonstrations ran once with a crash, but then executed
without a 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>
<mailto: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+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 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+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
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 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
