JDK-4753168 : self-suspend still has race with wait_for_ext_suspend_completion
  • Type: Bug
  • Component: vm-legacy
  • Sub-Component: jvmdi
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2002-09-25
  • Updated: 2002-11-13
  • Resolved: 2002-11-13
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.
Other
1.4.2 mantisFixed
Related Reports
Relates :  
JDK-4780782 - contmont001 test fails due to contended monitor reentry bug
Relates :  
JDK-4510838 - self-suspend race with GetCallTrace
Description
###@###.### 2002-09-25

During Mandy's code review of my fix for:

    4510838 4/2 self-suspend race with GetCallTrace

she pointed out that while the race was reduced, there was still
a window of vulnerability due to how the "suspend equivalent"
stuff was implemented.

This bug serves as a place holder for those stress related failures
that I've seen very intermittently.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis FIXED IN: mantis INTEGRATED IN: mantis
14-06-2004
EVALUATION ###@###.### 2002-10-08 The suspend-equivalent logic needs to be decoupled from ThreadBlockInVM objects since each "attribute" needs to be cleared under different circumstances. When a suspend-equivalent condition lifts, we need to check for a pending external suspend request (which we already do). If there is no pending external suspend request, then the suspend_equivalent flag needs to be cleared. If there is such a request, then the suspend_equivalent flag needs to be left on until java_suspend_self() sets the self_suspended() flag. This will insure that wait_for_ext_suspend_completion() returns consistent results.
11-06-2004
SUGGESTED FIX ###@###.### 2002-10-09 See attached 4753168-webrev.tar for proposed fix (pre-code review). ###@###.### 2002-10-11 See attached 4753168-webrev-cr1.tar for changes made during code review. ###@###.### 2002-11-20 This fix turned out to be incomplete and introduced a new bug: 4780782 3/3 contmont001 test fails due to contended monitor reentry bug This new bug affects more than the JVM/DI GetCurrentContendedMonitor() API. Any call to wait_for_ext_suspend_completion() can fail when the thread is blocked on a contended monitor reentry or on a RawMonitor entry. See 4780782 for the changes made to fix that bug.
11-06-2004
PUBLIC COMMENTS .
10-06-2004