Menu
▾
▴
[Oorexx-bugs] [ oorexx-Bugs-3103052 ] Error 11.1 not handled when using API via BSF4ooRexx
|
From: SourceForge.net <no...@so...> - 2010-11-07 13:58:05
|
Bugs item #3103052, was opened at 2010-11-04 13:28 Message generated for change (Comment added) made by bigrixx You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=3103052&group_id=119701 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: APIs Group: v4.0.1 >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: U. Zinngrebe (uzinngre) >Assigned to: Rick McGuire (bigrixx) Summary: Error 11.1 not handled when using API via BSF4ooRexx Initial Comment: When a stack overflow stops the rexx interpreter, it finishes orderly with error 11.1, see test script below. When the interpreter is called via API (through BSF4ooRexx), SIGNAL does not trap the error and the JNI crashes, see attached usenet post. Rony replied that the error lies in the API, NewRoutine() and CallRoutine() : > Running your Rexx program with rexx.exe directly, indeed yields that particular syntax error, > whereas running it via the ooRexx APIs (the NewRoutine()-API immediately followed by the > CallRoutine()-API) does not. Do you agree , is there more evidence necessary before you can look into the subject matter ? ---------------------------------------------------------------------------------------- C:\EPOPROGS\UserExe>rexx error11 REXX START REXX ERROR C:\EPOPROGS\UserExe>type error11 signal on any name error say 'REXX START' crash: call crash EXIT error: say 'REXX ERROR' EXIT ---------------------------------------------------------------------- >Comment By: Rick McGuire (bigrixx) Date: 2010-11-07 08:58 Message: The trap in question is occurring deep down in a system call at a location that is completely out of the interpreter's control. The detection of recursion limits is a predictive check based on checking the stack to determine if the stack has reached a minimum threshold size that can allow the interpreter to process the error condition. Once control has left the interpreter, things are out of our control and it's not really feasible to track the exception in such a way that an error can be raised in the Rexx program rather than being a terminal error. The behavior difference in this case is entirely determined by window of calls. Maybe the best that could done is to raise the limit, but that comes at the cost of limiting the number of recursions that can be made. ---------------------------------------------------------------------- Comment By: Rony G. Flatscher (orexx) Date: 2010-11-07 07:10 Message: A minimal runtime environment for BSF4ooRexx in which the aforementioned run-away Rexx-test-script can be run via Java got created and can be downloaded from <http://wi.wu.ac.at/rgf/rexx/bsf4oorexx/tmp/recursiveCrashViaJava/>. In essence: unzip the archive, change into the new subdirectory and run " runTestProgram.cmd". ---rony ---------------------------------------------------------------------- Comment By: Rony G. Flatscher (orexx) Date: 2010-11-07 06:08 Message: Mark, obviously I was not able to clearly communicate yesterday! :( What I meant to say with "Tried to run it in an isolated exe which used the same sequence of invoking the Rexx script as BSF4ooRexx.cc without yielding an error (ie. ooRexx was able to raise a syntax condition)." was that I created a stand-alone exe that used NewRoutine() and CallRoutine() and that that program executed the test-script correctly, ie. it raised error 11. --- Experimenting a little bit today, this is what I came up with: - Changing the stacksize for BSF4ooRexx.dll from 128KB to 256KB did not change anything, the JVM throws the "EXCEPTION_STACK_OVERFLOW" - Experimenting with the Java stack size, increasing the Java thread stack size using the -Xss512k switch has the following effects on the following different Java environments: -- on "Java 1.4.2_12-b03": stack exception after 1,300 recursive calls, increasing the Java stack-size per thread did not change the behaviour -- on "Java 1.5.0_10-b03": stack exception after 1,300 recursive calls, increasing the Java stack-size per thread did not change the behaviour -- on "Java 1.6.0_18-b07": test-program runs successfully, so increasing the Java stack-size solved the problem! So the 1.6/6 JVM can be tweaked to a per thread stack-size that allows that Rexx script to be successfully executed, i.e. not tearing down the JVM (and all its running Java programs). Not sure about Java 7 (do not have that installed as it is not yet voted upon in the JCP). As there are quite a few companies which are standardized on pre-Java-6 JVMs and because it is unclear what the behaviour on Java 7 will be, it would be desirable to get that runaway-Rexx test-script execute without the reported stack exception, which effect is very dramatic as the tore-down JVM will also cause any executing Java programs in that process to be killed without notice. Therefore it may be helpful to create and supply the environment to make it easy for the ooRexx developers to look into/monitor what is happening there, with the hope, that maybe something could be done on the ooRexx or BSF4ooRexx.dll side to intercept that exception early enough, such that the JVM does not get destroyed unexpectedly. ---------------------------------------------------------------------- Comment By: Mark Miesfeld (miesfeld) Date: 2010-11-06 16:01 Message: "Is it possible that BSF4ooRexx stack space (currently defined to be 128KB) could be the culprit? If so, I would enlarge it to 256 KB (can test this only tomorrow as I have to leave right now)." Yes of course it could. It could also be the case that it is the Java stack space that is used up. On the face of it, this doesn't seem to be an ooRexx bug. I've attached the code for a simple example that uses NewRoutine() and CallRoutine with the Rexx code: REXX START REXX ERROR C:\EPOPROGS\UserExe>type error11 signal on any name error say 'REXX START' crash: call crash EXIT error: say 'REXX ERROR' EXIT It works as expected. I.e. the program runs, the interpreter traps the recursion. I also tried it using Rexx code that does not trap the error. Again things worked as expected, the program did not crash and on the return from CallRoutine() there was a condition object with the 11.1 condition. ---------------------------------------------------------------------- Comment By: Rony G. Flatscher (orexx) Date: 2010-11-06 13:49 Message: Tried to run it in an isolated exe which used the same sequence of invoking the Rexx script as BSF4ooRexx.cc without yielding an error (ie. ooRexx was able to raise a syntax condition). Looking how far the the recursive calls had gone, it was about 2,700 in the standalone case, 1,700 in the context of BSF4ooRexx. Is it possible that BSF4ooRexx stack space (currently defined to be 128KB) could be the culprit? If so, I would enlarge it to 256 KB (can test this only tomorrow as I have to leave right now). [If not, I will try to come up with an easy to use environment which would allow for easy testing of this particular problem without any need to install BSF4ooRexx through its installation routines, although that would be easy and also would cleanly deinstall itself.] ---------------------------------------------------------------------- Comment By: Rick McGuire (bigrixx) Date: 2010-11-04 13:42 Message: You'll need to provide the a sample program that demonstrates this problem so we can reproduce this and debug it, plus all materials necessary to set up the environment. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684730&aid=3103052&group_id=119701 |