Re: [Oorexx-devel] Seeking help for fixing

2017-08-08 Thread Rony G. Flatscher 
Dear P.O.:

On 08.08.2017 12:43, P.O. Jonsson wrote:
> I cannot help you finding the cause of your problem but I can try to run the 
> program on various
> machines and collect some stats.
Thank you very much!

> I have downloaded the complete kit and can launch startTestProgressBar.rex
>
> I can see that the rexx program launches Java and the GUI show up with 3 
> buttons and a progress bar.
>
> What should I do next? I can click the buttons but see no response (except 
> the buttons frame
> changing color to blue). I can see rexxworker in the task list but that is 
> all.
>
> I have tried to click start some 100 times, no crash so far, I suspect I have 
> something set up
> incorrectly
>
> Here are the settings for the Machine
>
> macOS Sierra
... cut ...

you need a new version of BSF4ooRexx in order to become able to test this, 
therefore I created a new
installation package for MacOSX a few minutes ago and uploaded it to 
Sourceforge:
, the 
filename is:
"b4r_600_500_64Bit_macosx-20170807.zip
".


You would have to use a Terminal window to switch into the directory and launch 
the Rexx program
with "rexxj.sh" as it uses the GUI, e.g.:

rexxj.sh startTestProgressBar.rex

There are three possible scenarios:

  * the program runs through,
  * the program crashes,
  * the program hangs: if it hangs, then press Ctl-C in the Terminal window in 
order to kill the
hanging process.

---rony


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Seeking help for fixing

2017-08-08 Thread P.O. Jonsson 
Dear Rony,

I cannot help you finding the cause of your problem but I can try to run the 
program on various machines and collect some stats.

I have downloaded the complete kit and can launch startTestProgressBar.rex

I can see that the rexx program launches Java and the GUI show up with 3 
buttons and a progress bar.

What should I do next? I can click the buttons but see no response (except the 
buttons frame changing color to blue). I can see rexxworker in the task list 
but that is all.

I have tried to click start some 100 times, no crash so far, I suspect I have 
something set up incorrectly

Here are the settings for the Machine

macOS Sierra

POs-MacBook-Pro:~ po$ rexx -v
Open Object Rexx Version 5.0.0
Build date: Jul  7 2017
Addressing mode: 64

POs-MacBook-Pro:~ po$ java -version
java version "1.8.0_101"
Java(TM) SE Runtime Environment (build 1.8.0_101-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.101-b13, mixed mode)

POs-MacBook-Pro:~ po$  rexx -e "call bsf.cls;say ..b4r~version"
600.20170617

When I launch the program from the command line I get the following so I guess 
I have something incorrectly set up. Please advice what I should do next.

POs-MacBook-Pro:testapp po$ rexx testprogressbarcontroller
17 *-* myGuiDir=.my.app~testProgressBar.fxml
 7 *-* call setupInitializeGUI
REX0097E: Error 97 running /Users/po/testApp/testprogressbarcontroller.REX line 
17:  Object method not found.
REX0476E: Error 97.1:  Object ".MY.APP" does not understand message 
"TESTPROGRESSBAR.FXML".
POs-MacBook-Pro:testapp po$ 

POs-MacBook-Pro:testapp po$ bash rexxj.sh  testprogressbarcontroller.rex
RexxDispatcher.java: Throwable of type 
'org.rexxla.bsf.engines.rexx.RexxException' thrown while invoking Rexx:
getLocalizedMessage(): [BSF4ooRexx/routine/jniRexxRunProgram(), error 9:
17 *-* myGuiDir=.my.app~testProgressBar.fxml
Error 97 running /Users/po/testApp/testProgressBarController.rex line 17:  
Object method not found.
Error 97.1:  Object ".MY.APP" does not understand message 
"TESTPROGRESSBAR.FXML".]



Hälsningar/Regards/Grüsse,
P.O. Jonsson
oor...@jonases.se




> Am 07.08.2017 um 19:27 schrieb Rony G. Flatscher :
> 
> Dear René:
> 
> On 07.08.2017 17:10, René Jansen wrote:
>> Memory in multihreaded programs should be strictly guarded.
> AFAIK I am doing that everywhere in BSF4ooRexx.cc (cf. e.g. RgfAcquireLock() 
> and RgfReleaseLock()).
> 
>> I know of a few debuggers that can set memory modification watches/traps, 
>> one is OS/2’s kernel debugger and the other is MVS’s SLIP SET trap 
>> mechanism. From what I see sometimes the register save area is clobbered 
>> (assuming you are linking correctly) and you could set a memory modification 
>> trap on the register save areas on the stack. Or use any kind of dump 
>> service to dump all stacks and investigate the ones of the errant processes. 
>> One more thought: if Rexx has a concurrency lock, what would be the point of 
>> traversing Rexx code in more than one thread?
> There may be a multithreaded execution of Rexx programs and/or Java programs. 
> It should be (and has been) possible to call from any Rexx thread Java and 
> from any Java thread Rexx.
> 
> E.g. it has been possible in Java to use any number of RexxEngines (each 
> becoming a separate RexxInstance) on the same thread or running on different 
> threads concurrently.
> 
>> Wouldn’t it be beneficial to make sure your Java component only calls Rexx 
>> sequentially, so you can clean up everything between invocations?
> Everything gets cleaned up between invocations by design (e.g. there are 
> reference counters maintained for the objects in Rexx and Java registries 
> that control the life time of the stored objects; the key for the Rexx 
> registry - a directory - is the Rexx object's identityHash value; the key for 
> the Java registry - a Map - is usually the Java Object.toString() value, and 
> if needed a counter to make it a truly unique key).
> 
>> I did not read the whole thread very well, but does this also occur on Linux 
>> and macOS?
> Yes. 
> 
> (Tested it a few minutes ago on a fresh 64-bit Ubuntu ooRexx 5.0beta from 
> Sourceforge, August 1st, and the latest BSF4ooRexx, hs_err_-log-file is on 
> Dropbox.)
> 
> Best regards,
> 
> ---rony
> 
> 
> 
> On 7 Aug 2017, at 16:55, Rony G. Flatscher  > wrote:
>> 
>>> 
>>> One hint: after installing BSF4ooRexx one can use the menu "BSF4ooRexx -> 
>>> Samples" to get an explorer window. Then changing into "JavaFX" and loading 
>>> "index.html" will explain how to run those JavaFX nutshell examples. You 
>>> will see why I think it is so important to get the JavaFX support stable by 
>>> finding the root cause.
>>> 
>>> ---rony
>>> 
>>> On 07.08.2017 16:31, Rony G. Flatscher wrote:
 Dear Moritz:
 On 07.08.2017 15:02, Moritz Hoffmann wrote:
> without going into too much detail I would say it's hard to track down 
> the root

Re: [Oorexx-devel] Seeking help for fixing

2017-08-07 Thread Rony G. Flatscher 
Dear René:

On 07.08.2017 17:10, René Jansen wrote:
> Memory in multihreaded programs should be strictly guarded.
AFAIK I am doing that everywhere in BSF4ooRexx.cc (cf. e.g. RgfAcquireLock() 
and RgfReleaseLock()).

> I know of a few debuggers that can set memory modification watches/traps, one 
> is OS/2’s kernel
> debugger and the other is MVS’s SLIP SET trap mechanism. From what I see 
> sometimes the register
> save area is clobbered (assuming you are linking correctly) and you could set 
> a memory
> modification trap on the register save areas on the stack. Or use any kind of 
> dump service to dump
> all stacks and investigate the ones of the errant processes. One more 
> thought: if Rexx has a
> concurrency lock, what would be the point of traversing Rexx code in more 
> than one thread?
There may be a multithreaded execution of Rexx programs and/or Java programs. 
It should be (and has
been) possible to call from any Rexx thread Java and from any Java thread Rexx.

E.g. it has been possible in Java to use any number of RexxEngines (each 
becoming a separate
RexxInstance) on the same thread or running on different threads concurrently.

> Wouldn’t it be beneficial to make sure your Java component only calls Rexx 
> sequentially, so you
> can clean up everything between invocations?
Everything gets cleaned up between invocations by design (e.g. there are 
reference counters
maintained for the objects in Rexx and Java registries that control the life 
time of the stored
objects; the key for the Rexx registry - a directory - is the Rexx object's 
identityHash value; the
key for the Java registry - a Map - is usually the Java Object.toString() 
value, and if needed a
counter to make it a truly unique key).

> I did not read the whole thread very well, but does this also occur on Linux 
> and macOS?
Yes.

(Tested it a few minutes ago on a fresh 64-bit Ubuntu ooRexx 5.0beta from 
Sourceforge, August 1st,
and the latest BSF4ooRexx, hs_err_-log-file is on Dropbox.)

Best regards,

---rony



On 7 Aug 2017, at 16:55, Rony G. Flatscher > wrote:
>>
>> One hint: after installing BSF4ooRexx one can use the menu "BSF4ooRexx -> 
>> Samples" to get an
>> explorer window. Then changing into "JavaFX" and loading "index.html" will 
>> explain how to run
>> those JavaFX nutshell examples. You will see why I think it is so important 
>> to get the JavaFX
>> support stable by finding the root cause.
>>
>> ---rony
>>
>>
>> On 07.08.2017 16:31, Rony G. Flatscher wrote:
>>>
>>> Dear Moritz:
>>>
>>> On 07.08.2017 15:02, Moritz Hoffmann wrote:
 without going into too much detail I would say it's hard to track down the 
 root cause just from
 the stack traces. It still looks like a memory corruption issue that 
 you're facing, especially
 because it's not a deterministic failure.
>>> Yes, it definitely looks like it!
>>> :(
>>>
 I don't see why you want to call into Rexx from different Java threads. 
 Rexx has a global
 interpreter lock so you won't benefit from parallelism unless you have 
 fully independent Rexx
 instances.
>>> The reason is simple: when employing a Java GUI, then it should be possible 
>>> to write event
>>> handlers in Rexx and to interact with the GUI objects from Rexx.
>>>
>>> If an event is fired by Java, it will be fired on the GUI thread such that 
>>> the Rexx code is able
>>> to directly interact with the GUI objects.
>>>
>>> If a Rexx programmer needs to interact with GUI objects from a non-GUI 
>>> thread, then this would
>>> hang the GUI. Rather, one needs to make sure that the Rexx interaction gets 
>>> carried out on the
>>> GUI thread sometimes later. This is 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Seeking help for fixing

2017-08-07 Thread René Jansen 
Memory in multihreaded programs should be strictly guarded. I know of a few 
debuggers that can set memory modification watches/traps, one is OS/2’s kernel 
debugger and the other is MVS’s SLIP SET trap mechanism. From what I see 
sometimes the register save area is clobbered (assuming you are linking 
correctly) and you could set a memory modification trap on the register save 
areas on the stack. Or use any kind of dump service to dump all stacks and 
investigate the ones of the errant processes. One more thought: if Rexx has a 
concurrency lock, what would be the point of traversing Rexx code in more than 
one thread? Wouldn’t it be beneficial to make sure your Java component only 
calls Rexx sequentially, so you can clean up everything between invocations?

I did not read the whole thread very well, but does this also occur on Linux 
and macOS?

best regards,

René.



> On 7 Aug 2017, at 16:55, Rony G. Flatscher  wrote:
> 
> One hint: after installing BSF4ooRexx one can use the menu "BSF4ooRexx -> 
> Samples" to get an explorer window. Then changing into "JavaFX" and loading 
> "index.html" will explain how to run those JavaFX nutshell examples. You will 
> see why I think it is so important to get the JavaFX support stable by 
> finding the root cause.
> 
> ---rony
> 
> On 07.08.2017 16:31, Rony G. Flatscher wrote:
>> Dear Moritz:
>> On 07.08.2017 15:02, Moritz Hoffmann wrote:
>>> without going into too much detail I would say it's hard to track down the 
>>> root cause just from the stack traces. It still looks like a memory 
>>> corruption issue that you're facing, especially because it's not a 
>>> deterministic failure.
>> Yes, it definitely looks like it! 
>> :(
>> 
>>> I don't see why you want to call into Rexx from different Java threads. 
>>> Rexx has a global interpreter lock so you won't benefit from parallelism 
>>> unless you have fully independent Rexx instances.
>> The reason is simple: when employing a Java GUI, then it should be possible 
>> to write event handlers in Rexx and to interact with the GUI objects from 
>> Rexx. 
>> 
>> If an event is fired by Java, it will be fired on the GUI thread such that 
>> the Rexx code is able to directly interact with the GUI objects.
>> 
>> If a Rexx programmer needs to interact with GUI objects from a non-GUI 
>> thread, then this would hang the GUI. Rather, one needs to make sure that 
>> the Rexx interaction gets carried out on the GUI thread sometimes later. 
>> This is 
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Seeking help for fixing

2017-08-07 Thread Rony G. Flatscher 
One hint: after installing BSF4ooRexx one can use the menu "BSF4ooRexx -> 
Samples" to get an
explorer window. Then changing into "JavaFX" and loading "index.html" will 
explain how to run those
JavaFX nutshell examples. You will see why I think it is so important to get 
the JavaFX support
stable by finding the root cause.

---rony


On 07.08.2017 16:31, Rony G. Flatscher wrote:
>
> Dear Moritz:
>
> On 07.08.2017 15:02, Moritz Hoffmann wrote:
>> without going into too much detail I would say it's hard to track down the 
>> root cause just from
>> the stack traces. It still looks like a memory corruption issue that you're 
>> facing, especially
>> because it's not a deterministic failure.
> Yes, it definitely looks like it!
> :(
>
>> I don't see why you want to call into Rexx from different Java threads. Rexx 
>> has a global
>> interpreter lock so you won't benefit from parallelism unless you have fully 
>> independent Rexx
>> instances.
> The reason is simple: when employing a Java GUI, then it should be possible 
> to write event
> handlers in Rexx and to interact with the GUI objects from Rexx.
>
> If an event is fired by Java, it will be fired on the GUI thread such that 
> the Rexx code is able
> to directly interact with the GUI objects.
>
> If a Rexx programmer needs to interact with GUI objects from a non-GUI 
> thread, then this would
> hang the GUI. Rather, one needs to make sure that the Rexx interaction gets 
> carried out on the GUI
> thread sometimes later. This is possible by invoking Platfrom.runLater() (in 
> JavaFX, cf.
> )
>  or
> SwingUtilities.invokeLater (in Java swing, the predecessor of JavaFX, cf.
> ).
>
> It is in this scenario, executing Rexx code on the JavaFX GUI thread that 
> leads to the reported
> and observed crashes.
>
> BSF4ooRexx has been quite stable for a long time including using it on 
> multiple threads in parallel.
>
>>
>> Is the code available somewhere? Can you put it on Github or some other 
>> place so people can have
>> a look? (You can also create private repos there)
> Yes, I just prepared it, you (and everyone interested in taking a look) can 
> fetch it from my
> Dropbox, which also contains a "readme.txt" file (also attached to this mail):
>
> 
> .
>
> You would need (preferably 32-bit on Windows, because that is the ooRexx 
> version that is needed if
> interfacing with MS Office):
>
>   * ooRexx 5.0beta (latest installation builds from trunk:
> 
> 
>   * Java (64- and 32-bit can be installed in parallel): 
> 
>   * the latest BSF4ooRexx: 
> .
>
> You start the application by double-clicking "startTestProgressBar.rex" or 
> entering
> "startTestProgressBar.rex" in a new command line window (such that the 
> installation changes to the
> environment are honored).
>
> If there are any questions that I can answer, I am more than willing to try!
> ;)
>
> ---rony
>
> P.S.: "worker.rex" in this application uses a new ooRexx class named 
> "FxGUIThread" (defined at the
> end of "BSF.CLS") to send Rexx messages to Rexx objects (including the GUI 
> proxy objects)
> sometimes later on the JavaFX GUI thread.
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel

Re: [Oorexx-devel] Seeking help for fixing

2017-08-07 Thread Rony G. Flatscher 
After intensive further experimentations today, on one occasion I got the 
following
runtime-popup-error, if this matters:

---
Microsoft Visual C++ Runtime Library
---
Debug Error!

Program: C:\Program Files (x86)\ooRexx\rexx.dll
Module: C:\Program Files (x86)\ooRexx\rexx.dll
File: 
g:\oorexx.tmp\oorexxsvn\main\trunk\interpreter\classes\support\hashcollection.cpp
Line: 426

Run-Time Check Failure #0 - The value of ESP was not properly saved across 
a function call.  
This is usually a result of calling a function declared with one calling 
convention with a function 
pointer declared with a different calling convention.


(Press Retry to debug the application)

---
Abort   Retry   Ignore   
---

---

After extenisve testing all day it has become clear, that there are actually 
more and different
crash locations according to the call stacks. Somehow they depend on the 
intensity of updating the
GUI (the Rexx class method uses sysSleep() to sleep between the GUI update 
invocations).

One remarkable observation: so far *all* (!) the crashes occur *only* while 
executing Rexx code on
the JavaFX-GUI thread (which was not created by Rexx, but by Java)!

Occasionally, the program completes without an error!
:)

---rony



P.S.: It may be the case that the exceptions occur at random locations, 
nevertheless, maybe they
help to shed some light where the problems become visible therefore a few are 
enclosed.

Here two Java hs_error*log ("siginfo: ExceptionCode=0xc005, reading address 
0x") in case
that matters:

C  [rexx.dll+0x2a368]  MethodDictionary::getMethod+0x18
C  [rexx.dll+0x911e6]  RexxBehaviour::methodLookup+0x26
C  [rexx.dll+0x4c7f2]  RexxObject::messageSend+0x32
C  [rexx.dll+0xfce7c]  ExpressionStack::send+0x3c
C  [rexx.dll+0xfc809]  RexxExpressionMessage::evaluate+0x119
C  [rexx.dll+0x112afe]  RexxInstruction::evaluateArguments+0x5e
C  [rexx.dll+0xfbf1f]  RexxExpressionFunction::evaluate+0x6f
C  [rexx.dll+0xfc748]  RexxExpressionMessage::evaluate+0x58
C  [rexx.dll+0x112cee]  RexxInstructionExpression::evaluateExpression+0x3e
C  [rexx.dll+0x11288a]  RexxInstructionReturn::execute+0x2a
C  [rexx.dll+0xa93be]  /RexxActivation::run+0x39e/
C  [rexx.dll+0xb6948]  RexxCode::run+0x58
C  [rexx.dll+0x37243]  MethodClass::run+0x43
C  [rexx.dll+0x4c989]  RexxObject::messageSend+0xb9
C  [rexx.dll+0xfcee0]  ExpressionStack::send+0x40
C  [rexx.dll+0x10e586]  RexxInstructionMessage::execute+0x156
C  [rexx.dll+0xa93be]  /RexxActivation::run+0x39e/
C  [rexx.dll+0xb6948]  RexxCode::run+0x58
C  [rexx.dll+0x37243]  MethodClass::run+0x43
C  [rexx.dll+0x4c88c]  RexxObject::messageSend+0xcc
C  [rexx.dll+0x2b1b2]  RexxObject::sendMessage+0x22
C  [rexx.dll+0x4b1ba]  RexxObject::uninit+0x8a
C  [rexx.dll+0xd2894]  UninitDispatcher::run+0x24
C  [rexx.dll+0xb9815]  NativeActivation::run+0x85
C  [rexx.dll+0xee155]  /Activity::run+0x45/
C  [rexx.dll+0xdb505]  MemoryObject::runUninits+0xe5
C  [rexx.dll+0xb214f]  MemoryObject::checkUninitQueue+0x1f
C  [rexx.dll+0xedf0f] /Activity::exitCurrentThread+0x2f/
C  [rexx.dll+0x817dd]  ApiContext::~ApiContext+0x4d
C  [rexx.dll+0x89106]  NewStringFromAsciiz+0x96
C  [BSF4ooRexx.DLL+0x8b06

and another hs_error-log:

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native 
code)
C  [rexx.dll+0xb9409]  /NativeActivation::findRexxContext/+0x39
C  [rexx.dll+0xeb378]  /Activity::updateFrameMarkers/+0x38
C  [rexx.dll+0xeb54d]  /Activity::popStackFrame/+0x7d
C  [rexx.dll+0xa94dc]  /RexxActivation::run/+0x4bc
C  [rexx.dll+0xb6948]  RexxCode::run+0x58
C  [rexx.dll+0x37243]  MethodClass::run+0x43
C  [rexx.dll+0x4c88c]  RexxObject::messageSend+0xcc
C  [rexx.dll+0x24234]  RexxObject::sendMessage+0x24
C  [rexx.dll+0x84c2e]  SendMessage1+0x8e
C  [BSF4ooRexx.DLL+0x8c25]



And here three Visual Studio call stacks from three different crashes from 
today, again given in
case it matters:

Call Stack:

>   rexx.dll!MethodDictionary::getMethod(RexxString * 
methodName=0x7edb3268) Line 69C++
rexx.dll!RexxBehaviour::methodLookup(RexxString * 
messageName=0x7edb3268) Line 432  C++
rexx.dll!RexxObject::messageSend(RexxString * msgname=0x7edb3268, 
RexxObject * * arguments=0x1ca8f488, unsigned int count=1, ProtectedObject & 
result={...}) Line 815   C++
rexx.dll!RexxObject::operator_equal(RexxObject * operand=0x7dbcba08) 
Line 2633  C++
rexx.dll!RexxObject::callOperatorMethod(unsigned int methodOffset=11, 
RexxObject * argument=0x7dbcba08) Line 2955   C++
rexx.dll!RexxBinaryOperator::evaluate(RexxActivation * 
context=0x7e2aa258, ExpressionStack * stack=0x7e2aa320) Line 186 C++