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 ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
