Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#1160 Error 5 running line 0: System resources exhausted

4.1.2
invalid
nobody
None
none
1
2013-06-10
2013-02-12
No

A program, TestConcurrency5.java, accompanying a bug report in BSF4ooRexx (https://sourceforge.net/tracker/index.php?func=detail&aid=3604128&group_id=400586&atid=1660873) creates two Rexx interpreter instances in two different Java threads and constantly executes a Rexx program from Java, using the BSF4ooRexx external function package.

After about 30,000 executions of the Rexx program supplied as a string, the following error is raised by ooRexx and the program gets stopped:

Error 5 running line 0: System resources exhausted
Error 5.0: message n/a

Environment:

1 Attachments

Discussion

  • Mark Miesfeld
    Mark Miesfeld
    2013-02-13

    Rony,

    I don't consider this a bug. Systems do not have infinite resources and they are easily exhausted. When that happens the interpreter can not proceed and the error message informs the user as to why.

    This happened to me a few minutes ago when I tried to insert 30,000 items in a list view:

    C:\work.ooRexx\other\feature.requests\progress.indicator\list.example>addManyRows.rex
    284 - rows[i] = .LvFullRow~new(lvi, lvsi1, lvsi2, lvsi3, lvsi4, lvsi5, lvsi6, lvsi7, lvsi8, lvsi9, lvsi10
    , lvsi11, .true)
    207 - rows = self~createRows(list)
    6177 - self~initDialog
    7609 - if self~startIt(icon, modeless) \= 0
    73 - dlg~execute("SHOWTOP")
    Error 5 running C:\work.ooRexx\other\feature.requests\progress.indicator\list.example\addManyRows.rex line 284:
    System resources exhausted
    ^C
    C:\work.ooRexx\other\feature.requests\progress.indicator\list.example>

    You would need to explain clearly what about this you think is a bug.

     
  • Hi Mark,

    thank you for your feedback and efforts to look into this!

    The reason why I have been thinking that this is a bug is as follows:

    • there are two Rexx interpreter instances, each executing a very short program. I would have expected that upon ending the execution of these programs all resources of the program would be reclaimed, hence not using up constantly system resources,

    • the Rexx program that gets executed in this case creates an instance of a .Package supplying the filename of the Rexx package; as far as I know, once a package got created (and initialized in the process) in a Rexx interpreter instance, creating the same package later on would reuse the already loaded package (behaving like ::requires); therefore I have assumed that no additional resources get created on each invocation of that Rexx program that excercises .package~new(...), after the very first one per Rexx interpreter instance;

    • studying the output of the appr. 30.000 runs of the program in the two Rexx interpreter instances, occasionally .package~new(...) leads to new creations judging from the output that occurs in the initialisation part of the loaded package;


    This is the Rexx code that gets created on the Java side and passed on to the Rexx interpreter instance for execution:

    String rexxCode="say 'thread #' "+iNr+" '['||bsfGetTID()']' '"+manager+"'"+" .package~new('package.cls')\n";

    'bsfGetTID()' is an external Rexx function that returns the current thread id as a RexxString. 'iNr' and 'manager' are values from Java that are turned into strings, hence the Rexx code to execute may look like:
    "say 'thread #' 192837 '['||bsfGetTID()']' 'BSFManager@1e2f3a4b' .package~new('package.cls')\n"

    The content of 'package.cls' is simply:

    say 'package.cls loaded'
    exit


    Hmm, while writing everything in detail, I changed the Rexx code by inserting a ';' before ".package~new('package.cls')", which allowed me to run the program without losing system resources (forced ctl-c after a minute, ran 70.000+). Another subsequent change was to assign the new package object to a variable: "a=.package~new('package.cls')", which also allowed me to run the program without losing system resources (forced ctl-c after a minute, ran 80.000+).


    So I am not sure what causes the first Rexx program version (shown in detail above) to cause the Rexx interpreter instances to run out of system resources!

    Also, if ".package~new(...)' should behave like ::requires (load and initialize the package only on the very first invocation, i.e. behave like a singleton), then the package should be initialized only once in each Rexx interpreter instance. However, every couple of hundred invocations the package ('package.cls') initialization code gets run, which would be another bug. (Shall I report that separately?)

     
  • This is not a bug in ooRexx.

    It turns out that in the BSF4ooRexx framework Rexx interpreter instances do not get terminated. The system resources get exhausted after creating a couple of hundred thousands (!) Rexx interpreter instances, which one can understand! :)

    So this bug is an invalid one! Please invalidate it in the bug tracking system as well (I seem to not be able to do that myself).

     


Anonymous


Cancel   Add attachments