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"

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 *-*
     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 
POs-MacBook-Pro:testapp po$ 

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

P.O. Jonsson

> 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 (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,! 
> Oorexx-devel mailing list

Check out the vibrant tech community on one of the world's most
engaging tech sites,!
Oorexx-devel mailing list

Reply via email to