a while ago I reported a bug
<http://sourceforge.net/p/oorexx/bugs/1161/>, which originally
was reported in the BSF4ooRexx project, cf.
My inquiry of February has not yielded any reaction, possibly
because it was difficult to set up an environment to test.
So, today I got some time to create a zip-archive that will make it
easy to create the environment and execute the testprograms. The
zip-archive can be downloaded from
Just unzip the archive, create a command linw window, switch into
the directory "bugAndCrash20130530" (this contains a readme.txt file
as well, which is given after my signature below FYI) and execute
"setenv32.cmd" or "setenv64.cmd", depending on the bitness of your
ooRexx and Java (Java needs to be installed in the bitness that
ooRexx uses on your machine). These batch files set PATH and
CLASSPATH such, that one is abel to execute the test programs. Just
switch to the subdirectory "testprograms" and run "runBug2.cmd"
(this will crash ooRexx), and run "runBug1.cmd" (this one needs to
be interrupted by constantly pressing CTL-C and analyzing its
This way, the developers should be able to use their debug version
of ooRexx and run the test programs against it. In case of crashes
it should then be possible to analyze the cause.
This contains the BSF4ooRexx runtime environment for
Prerequisite: ooRexx and Java with the same bitness (either 32 or
Running the test programs, open a command line window:
- execute "setenv32.cmd" or "setenv64.cmd" depending on the
of your ooRexx and installed Java (bitness needs to match in
for BSF4ooRexx to be able to load Java); this script will
environment's PATH and CLASSPATH to point to .\bsf4oorexx
32 or 64 bit BSF4ooRexx dll
if everything went o.k., then you will see the output of
the test script testJava.rxj, showing the version of ooRexx,
and the BSF4ooRexx dll; otherwise please make sure that
Java are of the same bitness!
- go into the subdirectory "testprograms"
- execute runBug1.cmd, after approximately 15 seconds
continue to press CTL-C until the program returns
- analyze the logfile
look for "package.cls loaded, BSFGetTID()..."
- about the test program "ConcurrentPackageBug1.java":
program will create by default 16 (using runBug1.cmd
Java threads; for each Java thread a Rexx interpreter
created (each BSFManager instance creates and
separate Rexx interpreter instance which used for
a Rexx program);
bug: looking at the logfile you will see that each
interpreter instance will eventually reload the
"package.cls" which should not be the case
- execute runBug2.cmd, after a while the program will
- Java creates a hs_err_pidNN.log file containing the
of the JVM, a backtrace and a pointer to the cause of
crash, which is in native code (rexx.dll,
- the logfile
will contain the output of the test program up to and
to the point in time when the crash occurs
- about the test program
this program will create by default 16 (using
runBug2.cmd only 2)
Java threads; in each Java thread *each time* the
starts over *a new Rexx interpreter instance gets
that then executes the Rexx program "crash2.rxj" which
bug: crash of ooRexx
- zip-file with all of the files will be temporarily
- original report of the bug in the BSF4ooRexx tracking
- bug tracker item in the ooRexx project, cf.