Test CTE_REGTEST/Generic/4894903 is unpredictable

Refer to 5018598 for more details.

The testcase CTE_REGTEST/Generic/4894903 uses a shell script that sends
SIGQUIT signals to a java process, then sleeps for 1 second.
I've concluded that this will result in unpredictable results for this test.

It is a valuable testcase and I don't want it removed, but I think it
can be improved. It found a memory leak in the new hprof, but the testcase
would pass on some machines, fail on others, and if you varied the load
on a machine, you could make it pass or fail on the same machine.
It led me on a merry chase. ;^)

As far as I can tell, if you send a SIGQUIT to a Java process
it rejects all other SIGQUIT's until it's done processing the
one it has. This means if you bombard a process with SIGQUIT's,
only a fraction will actually cause anything to happen.

The testcase first sends 30 SIGQUIT's in 30 seconds...
Only a few of those would have been acted on. I don't think
this is what was expected in the testcase.

The sleep time needs to be increased, or better yet, the test.out file needs to
be probed for the "Full thread dump" pattern and in the case of
-Xrunhprof, the maybe the output
"Dumping Java heap ... allocation sites ... done."?

Or even simplier, something like:
 
  count=`egrep 'done.[\ \ ]*$' test.out`
  if [ ${count} = ${sigquit_count} ] ; then
  ...

(Of course there are probably other non-shell ways to do this)

If this was done, the 30 SIGQUITS could probably just be 5 or less, the sleeps
could be removed, and the testcase would be much more predictable,
and maybe execute faster.

A similar issue happens with startup, it sleeps for 20 seconds assuming that
the testcase will have stabilized. I discovered that in some situations, when
displaying over VPN, to a slow machine, 20 seconds is barely enough time.
It works, but just barely. I assume the testcase really wants the testcase
stabilized and maybe it should print something out to stdout when it has
reached main or something, then this sleep 20 could be removed too.

Let me know if you need any additional information.

###@###.### 2004-04-06