JDK-8152737 : Crash in RuntimeObject::put when object passed to JSObject::setMember is GCed
  • Type: Bug
  • Component: javafx
  • Sub-Component: web
  • Affected Version: 8u102,9
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-03-25
  • Updated: 2017-09-07
  • Resolved: 2016-03-29
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 8 JDK 9
8u102Fixed 9Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Description
The fix for JDK-8089681 causes a crash in some cases where the the Java object passed to setMember is reclaimed before a JavaScript call is made that eventually calls RuntimeObject::put. This was a missed case when testing the fix for JDK-8089681.

To reproduce, run the attached test program on a build that has the fix for JDK-8089681. It will crash immediately.
Comments
http://hg.openjdk.java.net/openjfx/9-dev/rt/rev/ecea43f5734c
29-03-2016

Looks good to me too.
28-03-2016

Looks good to me. +1
28-03-2016

webrev: http://cr.openjdk.java.net/~mbilla/8152737/webrev.00/ @kevin, i tested below scenarios with above patch 1. Tested all available applications (including TestFTE.java) related to the bug JDK-8089681 2. Unit test cases - PASSED 3. System Test case related to JDK-8089681 (yet to commit this system test case, though some existing launcher test cases are failing, which is a known issue) - PASSED 4. Checked with logs for creation of dummy object in case of java instance is already GC'ed Note: I retained the LOG_ERROR in case of failure of JLObject jlinstance(anInstance, true); to maintain the consistency with other files as part of the fix JDK-8089681
28-03-2016

As discussed earlier today, the likely fix is to always return a valid JavaClass object from JavaInstance::getClass() in JavaInstanceJSC.cpp, which involves fixing JavaClass constructor in JavaClassJSC.cpp. There is also one more potential problem in JavaArrayJSC.cpp which should be fixed (the object is not fully initialized if the array reference is garbage collected, which will lead to a crash at destruction time at the very least). @Murali: please incorporate this test as part of the unit tests you are writing for JDK-8151459
25-03-2016