[Oorexx-devel] FYI test suite and low memory Linux systems

[Mark M. <mie...@gm...>]

I thought I'd outline some problems I had on Debian 5.0 32-bit running
the test suite for the record.

I installed a Debian 32-bit system to compile on to test the
SysFileTree bug.  Which by the way disappears when the interpreter is
compiled on an actual Debian system rather than compiling on Kunbuntu.

But, the test suite had 81 failures.  The Kubuntu compiled interpreter
would also fail the same 81 tests.  In addition, when the test suite
finished, really a lot of the temporary files would not be deleted.

The failures were in ProcessInvocation.testGroup and
ProcessRexxStart.testGroup mostly, with a few thrown in for
CHAROUT.testGroup and some of the other stream tests.

After a lot of investigation yesterday, it looks to me like what
happens is this:  On a low memory system, (and probably only on Linux
where the OS will allow practically all memory to be consumed) the
test suite pushes the used memory right up to the max until it reaches
a point where the OS  no longer has enough memory available to start a
new process.

At that point the test suite continues to run fine and all tests that
do not require starting a new process will pass.  But anything in the
test suite that needs a new process fails.

For instance, the deleting of temporary files, the test suite uses a
construct like:

'rm -f' fileName '>/dev/null 2>&1'

Since the intepreter starts a new process to do that, it fails when
the OS can't start a new process, and the temporary file does not get
deleted.

Another example is the test that failed in CHAROUT.testGroup.  That
test essentially writes out a Rexx program that looks like this:

ret = charout( , "HELLO")
return ret

It then issues a command like this:

cmd = 'rexx' prgName '> tmpXXX_delete.me 2>&1'
cmd

and reads the output from the tmpXXX_delete.me file.  The test failed,
because a new process could not be started, the temp file was never
created and so it appeared there was not output from charout().

All of this made it hard to track down what was really happening.  For
instance the ProcessInvocation.testGroup and
ProcessRexxStart.testGroup tests ran perfectly fine if I ran them
individually.

For my part, I had had problems installing that stupid Debian and
ended up with a system where the memory was restricted to 800 MBs,
even though the system itself had 4 GBs.  I installed a big memory
kernel image and then the tests all passed.  And all the temporary
files were deleted at the end of the run.

I am pretty sure that this was the cause of what David was seeing back
in the beta stage on s390x.  If you recall he reported a bunch of test
cases failing and also that the temporary files were not getting
deleted.

--
Mark Miesfeld