Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-5027783

Test CTE_REGTEST/Generic/4894903 is unpredictable

    Details

    • Subcomponent:
    • Resolved In Build:
      b04
    • CPU:
      generic
    • OS:
      generic

      Description

      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

        Attachments

          Activity

            People

            • Assignee:
              asaha Abhijit Saha
              Reporter:
              ohair Kelly Ohair (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Imported:
                Indexed: