JDK-6474243 : suspicious jvmti code that uses oop unsafely across GC point
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 7
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris
  • CPU: generic
  • Submitted: 2006-09-22
  • Updated: 2010-12-03
  • Resolved: 2008-12-10
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 6 JDK 7 Other
6u14Fixed 7Fixed hs14Fixed
from ###@###.###

I was working on the ppc port and I came across some suspicious jvmdi
code so I looked at mustang and I see some suspicious jvmti code. Take a look
at TemplateTable::jvmti_post_field_access() here's the suspicious code:

if (has_tos) {
       // save object pointer before call_VM() clobbers it
         __ mov(Otos_i, Lscratch);
       } else {
         // Load top of stack (do not pop the value off the stack);
         __ ld_ptr(Lesp, Interpreter::expr_offset_in_bytes(0), Otos_i);
       __ verify_oop(Otos_i);
     // Otos_i: object pointer or NULL if static
     // Rcache: cache entry pointer
     __ call_VM(noreg, CAST_FROM_FN_PTR(address, InterpreterRuntime::post_field_access),
                Otos_i, Rcache);
     if (!is_static && has_tos) {
       __ mov(Lscratch, Otos_i);  // restore object pointer

It would appear to be hiding an oop in Lscratch. Hope it doesn't move. :-) It also
isn't clear if it really needs to be pushed on the expression stack so that
a gc will have the correct number of items on the stack.

Delete comment from another bug.

EVALUATION http://hg.openjdk.java.net/jdk7/hotspot-rt/hotspot/rev/b22701a8b88f

EVALUATION Summary: oop stored in unsafely in Lscratch noticed by visual inspection will not be updated by GC. Could cause an intermittent crash in jvmti, fixing for hs14. Tested by running nsk.jvmti.testlist tests with -XX:+VerifyOops (not bit rotten at the moment, yeah).