JDK-7023137 : resexhausted004 hangs nsk.jvmti subsuite run due to pop-up in JDK7-B131
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows
  • CPU: x86
  • Submitted: 2011-02-28
  • Updated: 2011-04-24
  • Resolved: 2011-04-24
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 7 Other
7Fixed hs21Fixed
Related Reports
Relates :  
JDK-7013634 - jvmti resexhausted001 can timeout or fail due to excessive thread creation
Description
In my baseline JDK7-B131 testing on WinXP, the following VM/NSK test
failed and caused a pop-up that stopped execution of the
nsk.jvmti subsuite:

    nsk/jvmti/ResourceExhausted/resexhausted004

Here is a report of failed nsk.jvmti tests that took longer
than 900 second (15 minutes) to execute:

$ get_tonga_test_times -f 900 vm-jvmti-prod-*/tonga.output/Tonga.log.log
log: vm-jvmti-prod-client-fast-comp.windows-i586/tonga.output/Tonga.log.log
log: vm-jvmti-prod-client-fast-mixed.windows-i586/tonga.output/Tonga.log.log
log: vm-jvmti-prod-client-prod-comp.windows-i586/tonga.output/Tonga.log.log
log: vm-jvmti-prod-client-prod-mixed.windows-i586/tonga.output/Tonga.log.log
log: vm-jvmti-prod-server-fast-comp.windows-i586/tonga.output/Tonga.log.log
    8446 nsk/jvmti/ResourceExhausted/resexhausted004 FAIL


log: vm-jvmti-prod-server-fast-mixed.windows-i586/tonga.output/Tonga.log.log
    1176 nsk/jvmti/ResourceExhausted/resexhausted004 FAIL


log: vm-jvmti-prod-server-prod-comp.windows-i586/tonga.output/Tonga.log.log
log: vm-jvmti-prod-server-prod-mixed.windows-i586/tonga.output/Tonga.log.log


For the vm-jvmti-prod-server-fast-mixed.windows-i586 config, I happened
to notice the pop-up and dismissed it so the timeout wasn't much longer
than the usual 15 minutes.

For the vm-jvmti-prod-server-fast-comp.windows-i586 config, I wasn't at
my keyboard so that timeout tool 140+ minutes. Ouch.
Please note that this test already has a known failure mode covered by:

    7013634 4/4 jvmti resexhausted001 can timeout or fail due to
                excessive thread creation

Also note that this test doesn't fail all the time. Much of the
time, yes, but not all the time.

I've filed this bug because the pop-up is new in JDK7-B131. Actually,
the pop-up can also be reproduced with JDK7-B130, but it didn't stop
execution of the subsuite. No, I have no idea why. My test log showed
an assertion failure for the test with JDK7-B130, but the test exited
with exit code 95 so the test wasn't logged as a failure. To reiterate:
a pop-up does happen with JDK7-B130 bits, but the subsuite execution
does not hang.
Observed the same pop-up in baseline testing for JDK7-B132 on
WinXP for the following VM/NSK test:

    nsk/jvmti/ResourceExhausted/resexhausted003

The configuration was:

    vm-jvmti-prod-server-fast-comp.windows-i586

$ cat vm-jvmti-prod-server-fast-comp.windows-i586/do_vm_common_tests.6996.version 
CompileOnly: compileonly *nsk*.*
VM option 'CompileOnly=nsk'
java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b132)
Java HotSpot(TM) Server VM (build 21.0-b03-fastdebug, compiled mode)
Comments
SUGGESTED FIX Here is the context diff for the proposed fix: $ hg diff share/vm/utilities/errorReporterHelper.cpp diff -r 9e7d2ac938b1 share/vm/utilities/errorReporterHelper.cpp --- a/share/vm/utilities/errorReporterHelper.cpp Mon Feb 28 15:35:46 2011 -0800 +++ b/share/vm/utilities/errorReporterHelper.cpp Tue Mar 01 10:09:48 2011 -0700 @@ -66,7 +66,6 @@ int ErrorReportingHelper::sendCurrentFile(char* buffer, size_t len ) { fileStream fs(_fh); - fs.set_need_close(true); fs.rewind();
01-03-2011
EVALUATION The hs_err_pid file descriptor is wrapped in a FILE object and that FILE object is passed into the ErrorReporting code. ErrorReportingHelper::sendCurrentFile() wraps the hs_err_pid FILE object with a fileStream and then sets the "need close" flag on that fileStream. sendCurrentFile() isn't the "owner" of the FILE object, let alone the underlying hs_err_pid file descriptor, so it should not do the close.
01-03-2011
EVALUATION Bad close() call src/share/vm/utilities/vmError.cpp 939 if (log.fd() != defaultStream::output_fd()) { 940 close(log.fd()); 941 }
28-02-2011