On Fri, 2010-09-03 at 23:11 -0400, David T. Lewis wrote:
> > Juan, do you have any ideas what changes between 2.6 and 2.7 might
> be
> > relevant, or what might be causing these failure patterns?
> 
> It is very possible that the problems are either in my unit tests, or
> in OSProcess/CommandShell. Many of the tests involve cooperating OS
> processes and are timing dependent. It would be good to understand
> what
> has changed between 2.6 and 2.7, but my working assumption would be
> that any changes in Cuis might make bugs in OSProcess/CommandShell
> more probable, but are not necessarily the root cause. The file
> locking
> tests are an example of tests that rely on cooperating OS processes,
> and that could fail due to timing issues of one sort of another.
> 
> I note that CommandShellTestCase in particular is a real torture
> test for process scheduling, and Pharo images have tended to choke
> on these tests. Again, I don't assume that Pharo is the root cause,
> just that the behavior seems to be different.
I ran only the OSProcess tests; I did not even file the CommandShell
stuff into the image.

I didn't mean to imply that I thought Cuis was necessarily the problem.
There does seem to be a difference between 2.6 and 2.7, since 2.7 is
sometimes all green but 2.6 never has been.  The changes in Cuis might
be a clue to where the problem lies.

In fact, I get failures in a stock squeak 4.1 image also.
UnixProcessAccessorTestCase>>testIsWritableForUserInGroup (1 error on
try 1)
UnixProcessUnixFileLockingTestCase>>testCooperatingProcesses04 (1
failure on try 2)
try 3: same results as try 2.

All tests use the same squeak 4.0 VM.


Tests that fail (as opposed to "error") don't seem to produce very
useful trace information in Cuis; when I click on the failed test I get
a stack trace that doesn't seem to have the error in the stack.  Can
anyone provide any insight into what's going on, or how to debug this
further?

I'm not sure how to retrieve the failure stack in squeak.  After some
fiddling I got a debugger to come up; it appears this may have been
triggered by a fresh run of the test.  The failure occurred near the end
of testCooperatingProcesses04 at 
	self assert: result = 'THIS IS A TEST 44'
The actual value of result was 'THIS IS 22TEST 44'.

Because the tests and the problem are timing sensitive, simply stepping
in with the debugger doesn't seem to work well.  I got a lot of errors
when I did so, I assume because various timeouts expired.

Ross