[Oorexx-devel] A crash in SysInterpreterInstance() always at the same number of invocations

2021-10-19 Thread Rony G. Flatscher 
While testing a simple Rexx script in a JSP there are crashes in 
RexxCreateInterpreter(), always at
the same invocation number (at # 168 plus a primodal interpreter instance).

Each of the 168 JSP-requests will cause a RexxInterpreter instance to be 
created to run the Rexx
scripts of a particular JSP invocation.

Here a snippet of the Java (32-bit, Java 8) hs_error logfile after creating a 
debug version of
ooRexx (32-bit, r12297):

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x77e08ca1, pid=9956, 
tid=0x30e4
#
# JRE version: Java(TM) SE Runtime Environment (8.0_171-b11) (build 
1.8.0_171-b11)
# Java VM: Java HotSpot(TM) Client VM (25.171-b11 mixed mode, sharing 
windows-x86 )
# Problematic frame:
*# C [rexx.dll+0xd8ca1] SysInterpreterInstance::initialize+0x181*
#
# Failed to write core dump. Minidumps are not enabled by default on client 
versions of Windows
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

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

Current thread (0x16601c00):  JavaThread "http-nio-42857-exec-10" daemon 
[_thread_in_native, id=12516, stack(0x18d1,0x18d8)]

siginfo: ExceptionCode=0xc005, reading address 0x

Registers:
EAX=0x75cd0360, EBX=0x1acaa874, ECX=0x669b30ac, EDX=0x
ESP=0x18d7e6a0, EBP=0x75be7170, ESI=0x, EDI=0x76a41700
EIP=0x77e08ca1, EFLAGS=0x00010206

Top of Stack: (sp=0x18d7e6a0)
0x18d7e6a0:   0002 0201 77e55598 00cc23d0
0x18d7e6b0:   1acaae58 18d7e6f8 1acaa858 1acab0f0
0x18d7e6c0:   00cc23d0 1acaae58 f1b9b533 77e1672a
0x18d7e6d0:   1acaa858 00cc23d0 f1b9b577 
0x18d7e6e0:   1acaa858 0002 1acaae58 18d7e71c
0x18d7e6f0:   77e3e651  18d7e728 77e14d6f
0x18d7e700:   1acaa4f0 00cc23d0 f1b9b4a7 
0x18d7e710:   1acaa858 1acaa4f0 00d7e708 18d7e748 

Instructions: (pc=0x77e08ca1)
0x77e08c81:   55 e5 77 6a 08 6a f4 ff d7 50 ff 15 30 e7 e8 77
0x77e08c91:   83 c4 08 50 ff 15 4c e6 e8 77 6a 02 8b f0 ff d5
0x77e08ca1:   8b 0e 83 c4 0c 89 08 6a 01 68 2f 27 d3 77 ff 15
0x77e08cb1:   74 e1 e8 77 8b 44 24 24 6a 01 89 03 ff 15 6c e1 


Register to memory mapping:

EAX=0x75cd0360 is an unknown value
EBX=0x1acaa874 is an unknown value
ECX=0x669b30ac is an unknown value
EDX=0x is an unknown value
ESP=0x18d7e6a0 is pointing into the stack for thread: 0x16601c00
EBP=0x75be7170 is an unknown value
ESI=0x is an unknown value
EDI=0x76a41700 is an unknown value


Stack: [0x18d1,0x18d8],  sp=0x18d7e6a0,  free space=441k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
code)
*C [rexx.dll+0xd8ca1] SysInterpreterInstance::initialize+0x181*

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  
org.rexxla.bsf.engines.rexx.RexxAndJava.jniRexxCreateInterpreterInstance([Ljava/lang/Object;)Ljava/lang/String;+0
j  
org.rexxla.bsf.engines.rexx.RexxAndJava.createRexxInterpreterInstance(Lorg/rexxla/bsf/engines/rexx/RexxConfiguration;)Ljava/lang/String;+60
j  
org.rexxla.bsf.engines.rexx.RexxEngine.apply(Ljava/lang/String;IILjava/lang/Object;Ljava/util/Vector;Ljava/util/Vector;)Ljava/lang/Object;+56
j  
org.rexxla.bsf.engines.rexx.jsr223.RexxScriptEngine.updateRexxEngine(Ljavax/script/ScriptContext;)V+40
j  
org.rexxla.bsf.engines.rexx.jsr223.RexxScriptEngine.compile(Ljava/lang/String;Ljava/lang/String;)Ljavax/script/CompiledScript;+805
j  
org.rexxla.bsf.engines.rexx.jsr223.RexxScriptEngine.eval(Ljava/lang/String;Ljavax/script/ScriptContext;)Ljava/lang/Object;+195
j  
javax.script.AbstractScriptEngine.eval(Ljava/lang/String;)Ljava/lang/Object;+6
j  org.rexxla.taglibs.jsr223.BaseImpl.doEndTag()I+7456
j  
org.apache.jsp.ooRexx_005fhelloWorld_jsp._jspx_meth_s_005fscript_005f0(Ljavax/servlet/jsp/PageContext;)Z+105
j  
org.apache.jsp.ooRexx_005fhelloWorld_jsp._jspService(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V+255
j  
org.apache.jasper.runtime.HttpJspBase.service(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V+3
j  
javax.servlet.http.HttpServlet.service(Ljavax/servlet/ServletRequest;Ljavax/servlet/ServletResponse;)V+36
j  
org.apache.jasper.servlet.JspServletWrapper.service(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;Z)V+411
j  
org.apache.jasper.servlet.JspServlet.serviceJspFile(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;Ljava/lang/String;Z)V+112
j  
org.apache.jasper.servlet.JspServlet.service(Ljavax/servlet/http/HttpServ

Re: [Oorexx-devel] A crash in SysInterpreterInstance() always at the same number of invocations

2021-10-19 Thread Rony G. Flatscher 
Tested against a 64-bit ooRexx (r12288) on Linux: the crashes occur there too, 
however at around 400
RexxCreateInterpreter() invocations.

---rony

On 19.10.2021 13:23, Rony G. Flatscher wrote:
>
> While testing a simple Rexx script in a JSP there are crashes in 
> RexxCreateInterpreter(), always
> at the same invocation number (at # 168 plus a primodal interpreter instance).
>
> Each of the 168 JSP-requests will cause a RexxInterpreter instance to be 
> created to run the Rexx
> scripts of a particular JSP invocation.
>
> Here a snippet of the Java (32-bit, Java 8) hs_error logfile after creating a 
> debug version of
> ooRexx (32-bit, r12297):
>
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x77e08ca1, pid=9956, 
> tid=0x30e4
> #
> # JRE version: Java(TM) SE Runtime Environment (8.0_171-b11) (build 
> 1.8.0_171-b11)
> # Java VM: Java HotSpot(TM) Client VM (25.171-b11 mixed mode, sharing 
> windows-x86 )
> # Problematic frame:
> *# C [rexx.dll+0xd8ca1] SysInterpreterInstance::initialize+0x181*
> #
> # Failed to write core dump. Minidumps are not enabled by default on 
> client versions of Windows
> #
> # If you would like to submit a bug report, please visit:
> #   http://bugreport.java.com/bugreport/crash.jsp
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #
>
> ---  T H R E A D  ---
>
> Current thread (0x16601c00):  JavaThread "http-nio-42857-exec-10" daemon 
> [_thread_in_native, id=12516, stack(0x18d1,0x18d8)]
>
> siginfo: ExceptionCode=0xc005, reading address 0x
>
> Registers:
> EAX=0x75cd0360, EBX=0x1acaa874, ECX=0x669b30ac, EDX=0x
> ESP=0x18d7e6a0, EBP=0x75be7170, ESI=0x, EDI=0x76a41700
> EIP=0x77e08ca1, EFLAGS=0x00010206
>
> Top of Stack: (sp=0x18d7e6a0)
> 0x18d7e6a0:   0002 0201 77e55598 00cc23d0
> 0x18d7e6b0:   1acaae58 18d7e6f8 1acaa858 1acab0f0
> 0x18d7e6c0:   00cc23d0 1acaae58 f1b9b533 77e1672a
> 0x18d7e6d0:   1acaa858 00cc23d0 f1b9b577 
> 0x18d7e6e0:   1acaa858 0002 1acaae58 18d7e71c
> 0x18d7e6f0:   77e3e651  18d7e728 77e14d6f
> 0x18d7e700:   1acaa4f0 00cc23d0 f1b9b4a7 
> 0x18d7e710:   1acaa858 1acaa4f0 00d7e708 18d7e748 
>
> Instructions: (pc=0x77e08ca1)
> 0x77e08c81:   55 e5 77 6a 08 6a f4 ff d7 50 ff 15 30 e7 e8 77
> 0x77e08c91:   83 c4 08 50 ff 15 4c e6 e8 77 6a 02 8b f0 ff d5
> 0x77e08ca1:   8b 0e 83 c4 0c 89 08 6a 01 68 2f 27 d3 77 ff 15
> 0x77e08cb1:   74 e1 e8 77 8b 44 24 24 6a 01 89 03 ff 15 6c e1 
>
>
> Register to memory mapping:
>
> EAX=0x75cd0360 is an unknown value
> EBX=0x1acaa874 is an unknown value
> ECX=0x669b30ac is an unknown value
> EDX=0x is an unknown value
> ESP=0x18d7e6a0 is pointing into the stack for thread: 0x16601c00
> EBP=0x75be7170 is an unknown value
> ESI=0x is an unknown value
> EDI=0x76a41700 is an unknown value
>
>
> Stack: [0x18d1,0x18d8],  sp=0x18d7e6a0,  free space=441k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code)
> *C [rexx.dll+0xd8ca1] SysInterpreterInstance::initialize+0x181*
>
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j  
> org.rexxla.bsf.engines.rexx.RexxAndJava.jniRexxCreateInterpreterInstance([Ljava/lang/Object;)Ljava/lang/String;+0
> j  
> org.rexxla.bsf.engines.rexx.RexxAndJava.createRexxInterpreterInstance(Lorg/rexxla/bsf/engines/rexx/RexxConfiguration;)Ljava/lang/String;+60
> j  
> org.rexxla.bsf.engines.rexx.RexxEngine.apply(Ljava/lang/String;IILjava/lang/Object;Ljava/util/Vector;Ljava/util/Vector;)Ljava/lang/Object;+56
> j  
> org.rexxla.bsf.engines.rexx.jsr223.RexxScriptEngine.updateRexxEngine(Ljavax/script/ScriptContext;)V+40
> j  
> org.rexxla.bsf.engines.rexx.jsr223.RexxScriptEngine.compile(Ljava/lang/String;Ljava/lang/String;)Ljavax/script/CompiledScript;+805
> j  
> org.rexxla.bsf.engines.rexx.jsr223.RexxScriptEngine.eval(Ljava/lang/String;Ljavax/script/ScriptContext;)Ljava/lang/Object;+195
> j  
> javax.script.AbstractScriptEngine.eval(Ljava/lang/String;)Ljava/lang/Object;+6
> j  org.rexxla.taglibs.jsr223.BaseImpl.doEndTag()I+7456
> j  
> org.apache.jsp.ooRexx_005fhelloWorld_jsp._jspx_meth_s_005fscript_005f0(Ljavax/servlet/jsp/PageContext;)Z+105
> j  
> org.apache.jsp.ooRexx_005fhelloWorld_jsp._jspService(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V+255
> j  
> org.apache.jasper.runtime.HttpJspBase.service(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V+3
> j  
> javax.servlet.http.HttpServlet.service(Ljavax/servlet/ServletRequest;Ljavax/servlet/ServletResponse;)V+36
>

Re: [Oorexx-devel] A crash in SysInterpreterInstance() always at the same number of invocations

2021-10-19 Thread Erich Steinböck 
Hi Rony,
a shot in the dark: the newly created InterpreterInstance might get GC'ed
before being added to the Interpreter's list of instances.

I just committed revision 12298 which might fix that.  You may want to try
it.
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] A crash in SysInterpreterInstance() always at the same number of invocations

2021-10-19 Thread Rony G. Flatscher 
Dear Erich,

On 19.10.2021 19:19, Erich Steinböck wrote:
> a shot in the dark: the newly created InterpreterInstance might get GC'ed 
> before being added to
> the Interpreter's list of instances.
>
> I just committed revision 12298 which might fix that.  You may want to try it.

will try it out right now, thank you very much!

---rony



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] A crash in SysInterpreterInstance() always at the same number of invocations

2021-10-19 Thread Rick McGuire 
On Tue, Oct 19, 2021 at 1:20 PM Erich Steinböck 
wrote:

> Hi Rony,
> a shot in the dark: the newly created InterpreterInstance might get GC'ed
> before being added to the Interpreter's list of instances.
>
> I just committed revision 12298 which might fix that.  You may want to try
> it.
>
I'm not convinced this will fix this issue. The first thing that happens
after the instance is created is to add it to the list of created
instances, which should protect it from GC. Even if the list needs to
expand at that point, the new instance should still be protect by the
allocation stack.

Rick



> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] A crash in SysInterpreterInstance() always at the same number of invocations

2021-10-19 Thread Rony G. Flatscher 
On 19.10.2021 19:53, Rony G. Flatscher wrote:
> Dear Erich,
>
> On 19.10.2021 19:19, Erich Steinböck wrote:
>> a shot in the dark: the newly created InterpreterInstance might get GC'ed 
>> before being added to
>> the Interpreter's list of instances.
>>
>> I just committed revision 12298 which might fix that.  You may want to try 
>> it.
> will try it out right now, thank you very much!

No, it did not fix the issue, it crashes at the same time (at the 168th JSP 
request), the hs_error
log file:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x77668ce1, pid=8012, 
tid=0x2c94
#
# JRE version: Java(TM) SE Runtime Environment (8.0_171-b11) (build 
1.8.0_171-b11)
# Java VM: Java HotSpot(TM) Client VM (25.171-b11 mixed mode, sharing 
windows-x86 )
# Problematic frame:
*# C [rexx.dll+0xd8ce1] SysInterpreterInstance::initialize+0x181*
#
# Failed to write core dump. Minidumps are not enabled by default on client 
versions of Windows
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

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

Current thread (0x16b96400):  JavaThread "http-nio-42857-exec-7" daemon 
[_thread_in_native, id=11412, stack(0x18e6,0x18ed)]

siginfo: ExceptionCode=0xc005, reading address 0x

Registers:
EAX=0x75cd0360, EBX=0x1d3e08d4, ECX=0x89786e6f, EDX=0x
ESP=0x18ecddd0, EBP=0x75be7170, ESI=0x, EDI=0x76a41700
EIP=0x77668ce1, EFLAGS=0x00010206

Top of Stack: (sp=0x18ecddd0)
0x18ecddd0:   0002 0201 776b5598 00ebbcf8
0x18ecdde0:   1cfeaae8 18ecde28 1d3e08b8 1d261cb0
0x18ecddf0:   00ebbcf8 1cfeaae8 915e1325 7767684a
0x18ecde00:   1d3e08b8 00ebbcf8 915e10e1 
0x18ecde10:   1d3e08b8 0002 1cfeaae8 18ecde5c
0x18ecde20:   7769e781  18ecde68 77674e23
0x18ecde30:   1d430808 00ebbcf8 915e10a1 
0x18ecde40:   776c04d8  1d430808 1d3e08b8 

Instructions: (pc=0x77668ce1)
0x77668cc1:   55 6b 77 6a 08 6a f4 ff d7 50 ff 15 30 e7 6e 77
0x77668cd1:   83 c4 08 50 ff 15 4c e6 6e 77 6a 02 8b f0 ff d5
0x77668ce1:   8b 0e 83 c4 0c 89 08 6a 01 68 16 27 59 77 ff 15
0x77668cf1:   74 e1 6e 77 8b 44 24 24 6a 01 89 03 ff 15 6c e1 


Register to memory mapping:

EAX=0x75cd0360 is an unknown value
EBX=0x1d3e08d4 is an unknown value
ECX=0x89786e6f is an unknown value
EDX=0x is an unknown value
ESP=0x18ecddd0 is pointing into the stack for thread: 0x16b96400
EBP=0x75be7170 is an unknown value
ESI=0x is an unknown value
EDI=0x76a41700 is an unknown value


Stack: [0x18e6,0x18ed],  sp=0x18ecddd0,  free space=439k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
code)
*C [rexx.dll+0xd8ce1] SysInterpreterInstance::initialize+0x181*

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j  
org.rexxla.bsf.engines.rexx.RexxAndJava.jniRexxCreateInterpreterInstance([Ljava/lang/Object;)Ljava/lang/String;+0
j  
org.rexxla.bsf.engines.rexx.RexxAndJava.createRexxInterpreterInstance(Lorg/rexxla/bsf/engines/rexx/RexxConfiguration;)Ljava/lang/String;+60
j  
org.rexxla.bsf.engines.rexx.RexxEngine.apply(Ljava/lang/String;IILjava/lang/Object;Ljava/util/Vector;Ljava/util/Vector;)Ljava/lang/Object;+56
j  
org.rexxla.bsf.engines.rexx.jsr223.RexxScriptEngine.updateRexxEngine(Ljavax/script/ScriptContext;)V+40
j  
org.rexxla.bsf.engines.rexx.jsr223.RexxScriptEngine.compile(Ljava/lang/String;Ljava/lang/String;)Ljavax/script/CompiledScript;+805
j  
org.rexxla.bsf.engines.rexx.jsr223.RexxScriptEngine.eval(Ljava/lang/String;Ljavax/script/ScriptContext;)Ljava/lang/Object;+195
J 10654 C1 
javax.script.AbstractScriptEngine.eval(Ljava/lang/String;)Ljava/lang/Object; 
(10 bytes) @ 0x01ee7d3c [0x01ee7d10+0x2c]
J 10207 C1 org.rexxla.taglibs.jsr223.BaseImpl.doEndTag()I (7572 bytes) @ 
0x028289ac [0x0281a530+0xe47c]
j  
org.apache.jsp.ooRexx_005fhelloWorld_jsp._jspx_meth_s_005fscript_005f0(Ljavax/servlet/jsp/PageContext;)Z+105
j  
org.apache.jsp.ooRexx_005fhelloWorld_jsp._jspService(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V+255
J 6664 C1 
org.apache.jasper.runtime.HttpJspBase.service(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletResponse;)V
 (7 bytes) @ 0x023df1fc [0x023df1d0+0x2c]
J 6378 C1 
javax.servlet.http.HttpServlet.service(Ljavax/servlet/ServletRequest;Ljavax/servlet/ServletResponse;)V
 (40 bytes) @ 0x01f8d02c [0x01f8cf80+0xac]
J 6654 C1 
org.apache.jasper.servlet.JspServletWrapper.service(Ljavax/servlet/http/HttpServletRequest;Ljavax/servlet/http/HttpServletR

Re: [Oorexx-devel] A crash in SysInterpreterInstance() always at the same number of invocations

2021-10-19 Thread Rony G. Flatscher 
Short of anything else:

  * on the Linux box (it is four times slower than my current Windows laptop) 
when the crash point
comes nearer the times between the last (appr. ten) JSP requests become 
longer and longer, as if
the Rexx executions slow down from RexxInterpreter instance to 
RexxInterpreter instance. (The
setup is a Java client using http requests to fetch the ooRexx-JSP from the 
Tomcat 9 and Tomcat
10 server. The Tomcat servers have a taglib that allows ooRexx scripts to 
be embedded and that
get run upon each request. The test JSP has a single Rexx script that 
outputs text with the
result of .dateTime~new, cf. the JSP file below.)

  * not sure whether this is relevant: .input, .output and .error get 
redirected to Rexx objects
that forward to the Java Reader and Writers supplied by the Java scripting 
framework (.stdin,
.stdout, .stderr remain untouched).

---rony

P.S.: here the content of ooRexx_helloWorld.jsp:

<%@ page session="false" pageEncoding="UTF-8" contentType="text/html; 
charset=UTF-8" %>
<%@ taglib uri="http://rexxla.org/taglibs/jsr223"; prefix="s" %>





body { background-color: ivory; }

ooRexx_helloWorld.jsp (Title)


"Hello, world ..." (ooRexx)
*say 'Hello, world, this is ooRexx speaking at:'
.dateTime~new ''*


Done.




On 19.10.2021 20:07, Rony G. Flatscher wrote:
> On 19.10.2021 19:53, Rony G. Flatscher wrote:
>> Dear Erich,
>>
>> On 19.10.2021 19:19, Erich Steinböck wrote:
>>> a shot in the dark: the newly created InterpreterInstance might get GC'ed 
>>> before being added to
>>> the Interpreter's list of instances.
>>>
>>> I just committed revision 12298 which might fix that.  You may want to try 
>>> it.
>> will try it out right now, thank you very much!
>
> No, it did not fix the issue, it crashes at the same time (at the 168th JSP 
> request), the hs_error
> log file:
>
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x77668ce1, pid=8012, 
> tid=0x2c94
> #
> # JRE version: Java(TM) SE Runtime Environment (8.0_171-b11) (build 
> 1.8.0_171-b11)
> # Java VM: Java HotSpot(TM) Client VM (25.171-b11 mixed mode, sharing 
> windows-x86 )
> # Problematic frame:
> *# C [rexx.dll+0xd8ce1] SysInterpreterInstance::initialize+0x181*
> #
> # Failed to write core dump. Minidumps are not enabled by default on 
> client versions of Windows
> #
> # If you would like to submit a bug report, please visit:
> #   http://bugreport.java.com/bugreport/crash.jsp
> # The crash happened outside the Java Virtual Machine in native code.
> # See problematic frame for where to report the bug.
> #
>
> ---  T H R E A D  ---
>
> Current thread (0x16b96400):  JavaThread "http-nio-42857-exec-7" daemon 
> [_thread_in_native, id=11412, stack(0x18e6,0x18ed)]
>
> siginfo: ExceptionCode=0xc005, reading address 0x
>
> Registers:
> EAX=0x75cd0360, EBX=0x1d3e08d4, ECX=0x89786e6f, EDX=0x
> ESP=0x18ecddd0, EBP=0x75be7170, ESI=0x, EDI=0x76a41700
> EIP=0x77668ce1, EFLAGS=0x00010206
>
> Top of Stack: (sp=0x18ecddd0)
> 0x18ecddd0:   0002 0201 776b5598 00ebbcf8
> 0x18ecdde0:   1cfeaae8 18ecde28 1d3e08b8 1d261cb0
> 0x18ecddf0:   00ebbcf8 1cfeaae8 915e1325 7767684a
> 0x18ecde00:   1d3e08b8 00ebbcf8 915e10e1 
> 0x18ecde10:   1d3e08b8 0002 1cfeaae8 18ecde5c
> 0x18ecde20:   7769e781  18ecde68 77674e23
> 0x18ecde30:   1d430808 00ebbcf8 915e10a1 
> 0x18ecde40:   776c04d8  1d430808 1d3e08b8 
>
> Instructions: (pc=0x77668ce1)
> 0x77668cc1:   55 6b 77 6a 08 6a f4 ff d7 50 ff 15 30 e7 6e 77
> 0x77668cd1:   83 c4 08 50 ff 15 4c e6 6e 77 6a 02 8b f0 ff d5
> 0x77668ce1:   8b 0e 83 c4 0c 89 08 6a 01 68 16 27 59 77 ff 15
> 0x77668cf1:   74 e1 6e 77 8b 44 24 24 6a 01 89 03 ff 15 6c e1 
>
>
> Register to memory mapping:
>
> EAX=0x75cd0360 is an unknown value
> EBX=0x1d3e08d4 is an unknown value
> ECX=0x89786e6f is an unknown value
> EDX=0x is an unknown value
> ESP=0x18ecddd0 is pointing into the stack for thread: 0x16b96400
> EBP=0x75be7170 is an unknown value
> ESI=0x is an unknown value
> EDI=0x76a41700 is an unknown value
>
>
> Stack: [0x18e6,0x18ed],  sp=0x18ecddd0,  free space=439k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
> code)
> *C [rexx.dll+0xd8ce1] SysInterpreterInstance::initialize+0x181*
>
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j  
> org.rexxla.bsf.engines.rexx.RexxAndJava.jniRexxCreateInterpreterInstance([Ljava/lang/Object;)Ljava/lang/String;+0
> j  
> org.rexxla.bsf.engines.rexx.RexxAnd

Re: [Oorexx-devel] A crash in SysInterpreterInstance() always at the same number of invocations

2021-10-28 Thread Rony G. Flatscher 
Tried for some time now to duplicate the error without Java in the picture by 
duplicating some of
the code patterns that get applied there in c++ and an ooRexx program.

However so far I was not able to recreate that crash.

The only thing that I can provoke (on a Windows box with 32-bit ooRexx) is a 
condition indicating
that there are no more threads available from the system:

G:\oorexx.tmp\bugs\sysinterpreter>testInterpreterInstances.exe 600
Created interpreter instance version=5.0.0 language level=6.05

Using interpreter to execute dii.rex


result=[a Package]

clzElapser   =[0260F4A8]
clzRII   =[02608538]
clzNoOp  =[02604B20]
r_redirect   =[025FA578]
r_do_requires=[0261AA98]
pgk_requires =[02617978]
elapseTime   =[600]
   129 *-* reply  -- sleep
   124 *-* self~sleep  -- not yet slept?
   104 *-* .waiter~new(random(1,750)/1000)~wait -- wait a bit (terminates a 
RII randomly)
Error 48 running G:\oorexx.tmp\bugs\sysinterpreter\dii.rex line 129:  
Failure in system service.
Error somewhere in rii # [30320], aborting ...
Error 48.1:  Failure in system service: Error creating thread.
---> standardConditionMsg(...), start:
   102 *-* reply -- return
Error 48 running G:\oorexx.tmp\bugs\sysinterpreter\dii.rex line 102: 
Failure in system service.
Error 48.001:  Failure in system service: Error creating thread.
<--- standardConditionMsg(...), end.

"rii" stands for "Rexx interpreter instance", the condition occurs therefore at 
Rexx intepreter
instance # 30,320 (sic!). The threads get excercised by Rexx code using reply 
at two locations (one
location does a syssleep for random time after which the rii gets terminated).

In the case you may see utility in this particular scenario please let me know 
and I submit a tidied
up version of the code (c++ plus an ooRexx program).

---

Short of new ideas, is there anything I could try to shed more light on this 
problem while
excercising the Java server page test?

---rony


On 19.10.2021 20:19, Rony G. Flatscher wrote:
>
> Short of anything else:
>
>   * on the Linux box (it is four times slower than my current Windows laptop) 
> when the crash point
> comes nearer the times between the last (appr. ten) JSP requests become 
> longer and longer, as
> if the Rexx executions slow down from RexxInterpreter instance to 
> RexxInterpreter instance.
> (The setup is a Java client using http requests to fetch the ooRexx-JSP 
> from the Tomcat 9 and
> Tomcat 10 server. The Tomcat servers have a taglib that allows ooRexx 
> scripts to be embedded
> and that get run upon each request. The test JSP has a single Rexx script 
> that outputs text
> with the result of .dateTime~new, cf. the JSP file below.)
>
>   * not sure whether this is relevant: .input, .output and .error get 
> redirected to Rexx objects
> that forward to the Java Reader and Writers supplied by the Java 
> scripting framework (.stdin,
> .stdout, .stderr remain untouched).
>
> ---rony
>
> P.S.: here the content of ooRexx_helloWorld.jsp:
>
> <%@ page session="false" pageEncoding="UTF-8" contentType="text/html; 
> charset=UTF-8" %>
> <%@ taglib uri="http://rexxla.org/taglibs/jsr223"; prefix="s" %>
> 
> 
> 
> 
> 
> body { background-color: ivory; }
> 
> ooRexx_helloWorld.jsp (Title)
> 
> 
> "Hello, world ..." (ooRexx)
> *say 'Hello, world, this is ooRexx speaking at:'
> .dateTime~new ''*
>
> 
> Done.
> 
> 
>
>
> On 19.10.2021 20:07, Rony G. Flatscher wrote:
>> On 19.10.2021 19:53, Rony G. Flatscher wrote:
>>> Dear Erich,
>>>
>>> On 19.10.2021 19:19, Erich Steinböck wrote:
 a shot in the dark: the newly created InterpreterInstance might get GC'ed 
 before being added to
 the Interpreter's list of instances.

 I just committed revision 12298 which might fix that.  You may want to try 
 it.
>>> will try it out right now, thank you very much!
>>
>> No, it did not fix the issue, it crashes at the same time (at the 168th JSP 
>> request), the
>> hs_error log file:
>>
>> #
>> # A fatal error has been detected by the Java Runtime Environment:
>> #
>> #  EXCEPTION_ACCESS_VIOLATION (0xc005) at pc=0x77668ce1, pid=8012, 
>> tid=0x2c94
>> #
>> # JRE version: Java(TM) SE Runtime Environment (8.0_171-b11) (build 
>> 1.8.0_171-b11)
>> # Java VM: Java HotSpot(TM) Client VM (25.171-b11 mixed mode, sharing 
>> windows-x86 )
>> # Problematic frame:
>> *# C [rexx.dll+0xd8ce1] SysInterpreterInstance::initialize+0x181*
>> #
>> # Failed to write core dump. Minidumps are not enabled by default on 
>> client versions of Windows
>> #
>> # If you would like to submit a bug report, please visit:
>> #   http://bugreport.java.com/bugreport/crash.jsp
>> # The crash happened o

Re: [Oorexx-devel] A crash in SysInterpreterInstance() always at the same number of invocations

2021-11-17 Thread Rony G. Flatscher 
Just another observation: tested the Java web server with the same Rexx JSP 
with the 32-bit DEBUG
version of ooRexx from trunk and it does not crash!

---rony


On 19.10.2021 14:15, Rony G. Flatscher wrote:
>
> Tested against a 64-bit ooRexx (r12288) on Linux: the crashes occur there 
> too, however at around
> 400 RexxCreateInterpreter() invocations.
>
> ---rony
>
> On 19.10.2021 13:23, Rony G. Flatscher wrote:
>>
>> While testing a simple Rexx script in a JSP there are crashes in 
>> RexxCreateInterpreter(), always
>> at the same invocation number (at # 168 plus a primodal interpreter 
>> instance).
>>
>> Each of the 168 JSP-requests will cause a RexxInterpreter instance to be 
>> created to run the Rexx
>> scripts of a particular JSP invocation.
>>
>> Here a snippet of the Java (32-bit, Java 8) hs_error logfile after creating 
>> a debug version of
>> ooRexx (32-bit, r12297):
>>



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] A crash in SysInterpreterInstance() always at the same number of invocations

2021-11-18 Thread Rony G. Flatscher 
For completeness: now had the possibility to create and test three versions of 
ooRexx r12308:
"release", "releaseWithDebugInfo" and "Debug": "release" and 
"releaseWithDebugInfo" crash always at
the same Rexx instance creation (# 168 on 32-bit Windows). The "debug" version 
runs without a crash.

---rony

P.S.: The Tomcat 9 Java web server resides on the same Windows 32-bit machine 
using the installed
32-bit ooRexx to serve RexxServerPages/JSP. The Java exception handler kicks in 
and creates
hs_error*.log files, unfortunately without the rexx.dll symbols which should be 
available with the
"releaseWithDebugInfo".

On 17.11.2021 19:22, Rony G. Flatscher wrote:
> Just another observation: tested the Java web server with the same Rexx JSP 
> with the 32-bit DEBUG
> version of ooRexx from trunk and it does not crash!
>
> ---rony
>
>
> On 19.10.2021 14:15, Rony G. Flatscher wrote:
>> Tested against a 64-bit ooRexx (r12288) on Linux: the crashes occur there 
>> too, however at around
>> 400 RexxCreateInterpreter() invocations.
>>
>> ---rony
>>
>> On 19.10.2021 13:23, Rony G. Flatscher wrote:
>>> While testing a simple Rexx script in a JSP there are crashes in 
>>> RexxCreateInterpreter(), always
>>> at the same invocation number (at # 168 plus a primodal interpreter 
>>> instance).
>>>
>>> Each of the 168 JSP-requests will cause a RexxInterpreter instance to be 
>>> created to run the Rexx
>>> scripts of a particular JSP invocation.
>>>
>>> Here a snippet of the Java (32-bit, Java 8) hs_error logfile after creating 
>>> a debug version of
>>> ooRexx (32-bit, r12297):
>>>
>


___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] A crash in SysInterpreterInstance() always at the same number of invocations

2021-11-18 Thread Rony G. Flatscher 
Just filed a bug (with the code attached) at 
.

---rony


On 18.11.2021 13:38, Rony G. Flatscher wrote:
> For completeness: now had the possibility to create and test three versions 
> of ooRexx r12308:
> "release", "releaseWithDebugInfo" and "Debug": "release" and 
> "releaseWithDebugInfo" crash always at
> the same Rexx instance creation (# 168 on 32-bit Windows). The "debug" 
> version runs without a crash.
>
> ---rony
>
> P.S.: The Tomcat 9 Java web server resides on the same Windows 32-bit machine 
> using the installed
> 32-bit ooRexx to serve RexxServerPages/JSP. The Java exception handler kicks 
> in and creates
> hs_error*.log files, unfortunately without the rexx.dll symbols which should 
> be available with the
> "releaseWithDebugInfo".
>
> On 17.11.2021 19:22, Rony G. Flatscher wrote:
>> Just another observation: tested the Java web server with the same Rexx JSP 
>> with the 32-bit DEBUG
>> version of ooRexx from trunk and it does not crash!
>>
>> ---rony
>>
>>
>> On 19.10.2021 14:15, Rony G. Flatscher wrote:
>>> Tested against a 64-bit ooRexx (r12288) on Linux: the crashes occur there 
>>> too, however at around
>>> 400 RexxCreateInterpreter() invocations.
>>>
>>> ---rony
>>>
>>> On 19.10.2021 13:23, Rony G. Flatscher wrote:
 While testing a simple Rexx script in a JSP there are crashes in 
 RexxCreateInterpreter(), always
 at the same invocation number (at # 168 plus a primodal interpreter 
 instance).

 Each of the 168 JSP-requests will cause a RexxInterpreter instance to be 
 created to run the Rexx
 scripts of a particular JSP invocation.

 Here a snippet of the Java (32-bit, Java 8) hs_error logfile after 
 creating a debug version of
 ooRexx (32-bit, r12297):




___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] A crash in SysInterpreterInstance() always at the same number of invocations

2021-11-22 Thread Michael Lueck 

Greetings ooRexx'ers,

Rony G. Flatscher wrote:

Just filed a bug (with the code attached) at 
.



So I read through that thread... seems possibly Rick spotted the defect in 
Rony's code, and therefor cleared ooRexx of any defect in this area?

I am thankful,

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/


___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] A crash in SysInterpreterInstance() always at the same number of invocations

2021-11-22 Thread Rony G. Flatscher 
On 22.11.2021 17:15, Michael Lueck wrote:
> Greetings ooRexx'ers,
>
> Rony G. Flatscher wrote:
>> Just filed a bug (with the code attached) at 
>> .
>
>
> So I read through that thread... seems possibly Rick spotted the defect in 
> Rony's code, and
> therefor cleared ooRexx of any defect in this area?

No.

My test code was without Java trying to mimic what happens in the Java based 
web server (so the code
was created ad hoc from scratch, is relatively complex and I have permutated it 
over the weeks and
in one scenario got a crash that I reported with the code). The termination of 
Rexx interpreter
instances (rii) occurred in a native method but in the context of the very same 
rii, which caused in
this scenario the crash (due to exhausted system resources).

The true ooRexx crash occurs in a different scenario running in a Tomcat (Java) 
process. Today I
became able to create mini dumps on the Java web server in case a crash occurs. 
This is what I
reported today (the error message is: "Unhandled exception at 0x634D8CE1 
(rexx.dll) in
hs_err_pid1628.mdmp: 0xC005: Access violation reading location 0x." 
) in the e-mail
subject changed to "MSVS MiniDump created, more concrete infos ...".

---rony



___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] A crash in SysInterpreterInstance() always at the same number of invocations

2021-11-22 Thread Rick McGuire 
I'm not sure what in that particular line could cause a crash, but it might
be because we do the reinitialization every time an interpreter instance is
created. Those are thing that should only be one once per process, so I
rearranged the code a bit.

Rick

On Mon, Nov 22, 2021 at 11:37 AM Rony G. Flatscher 
wrote:

> On 22.11.2021 17:15, Michael Lueck wrote:
> > Greetings ooRexx'ers,
> >
> > Rony G. Flatscher wrote:
> >> Just filed a bug (with the code attached) at <
> https://sourceforge.net/p/oorexx/bugs/1789/>.
> >
> >
> > So I read through that thread... seems possibly Rick spotted the defect
> in Rony's code, and
> > therefor cleared ooRexx of any defect in this area?
>
> No.
>
> My test code was without Java trying to mimic what happens in the Java
> based web server (so the code
> was created ad hoc from scratch, is relatively complex and I have
> permutated it over the weeks and
> in one scenario got a crash that I reported with the code). The
> termination of Rexx interpreter
> instances (rii) occurred in a native method but in the context of the very
> same rii, which caused in
> this scenario the crash (due to exhausted system resources).
>
> The true ooRexx crash occurs in a different scenario running in a Tomcat
> (Java) process. Today I
> became able to create mini dumps on the Java web server in case a crash
> occurs. This is what I
> reported today (the error message is: "Unhandled exception at 0x634D8CE1
> (rexx.dll) in
> hs_err_pid1628.mdmp: 0xC005: Access violation reading location
> 0x." ) in the e-mail
> subject changed to "MSVS MiniDump created, more concrete infos ...".
>
> ---rony
>
>
>
> ___
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
>


instance.patch
Description: Binary data
___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] A crash in SysInterpreterInstance() always at the same number of invocations

2021-11-22 Thread Rony G. Flatscher 
On 22.11.2021 18:11, Rick McGuire wrote:
> I'm not sure what in that particular line could cause a crash, but it might 
> be because we do the
> reinitialization every time an interpreter instance is created. Those are 
> thing that should only
> be one once per process, so I rearranged the code a bit.

thank you, that fixes it!

---rony

>
> On Mon, Nov 22, 2021 at 11:37 AM Rony G. Flatscher  > wrote:
>
> On 22.11.2021 17:15, Michael Lueck wrote:
> > Greetings ooRexx'ers,
> >
> > Rony G. Flatscher wrote:
> >> Just filed a bug (with the code attached) at 
>  >.
> >
> >
> > So I read through that thread... seems possibly Rick spotted the defect 
> in Rony's code, and
> > therefor cleared ooRexx of any defect in this area?
>
> No.
>
> My test code was without Java trying to mimic what happens in the Java 
> based web server (so
> the code
> was created ad hoc from scratch, is relatively complex and I have 
> permutated it over the weeks and
> in one scenario got a crash that I reported with the code). The 
> termination of Rexx interpreter
> instances (rii) occurred in a native method but in the context of the 
> very same rii, which
> caused in
> this scenario the crash (due to exhausted system resources).
>
> The true ooRexx crash occurs in a different scenario running in a Tomcat 
> (Java) process. Today I
> became able to create mini dumps on the Java web server in case a crash 
> occurs. This is what I
> reported today (the error message is: "Unhandled exception at 0x634D8CE1 
> (rexx.dll) in
> hs_err_pid1628.mdmp: 0xC005: Access violation reading location 
> 0x." ) in the e-mail
> subject changed to "MSVS MiniDump created, more concrete infos ...".
>
> ---rony
>

___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel