JDK-5074396 : enabling/disabling of SingleStep on a running java thread causes crash
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 6
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic,sparc,itanium
  • Submitted: 2004-07-15
  • Updated: 2005-03-01
  • Resolved: 2004-08-30
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 JDK 6
5.0u4Fixed 6 mustangFixed
Related Reports
Duplicate :  
Description

Name: pvR10198			Date: 07/15/2004


------------------------------------------------------
Tests    : nsk/jvmti/scenarios/hotswap/HS101/hs101t003
           nsk/jvmti/scenarios/hotswap/HS101/hs101t006
           nsk/jvmti/scenarios/hotswap/HS102/hs102t002
Mode     : generic
Platform : generic
OS       : generic
JDK      : 1.5.0-beta3-b57
------------------------------------------------------

The tests use the same HotSwap agent which source code can be found
at GammaBase/Bugs/<this bug number>/share/jvmti/hotswap directory.

Debuggee part of the tests exercise some methods in a tight loop
while the agent periodically redefines classes of specified
package which include the exercised methods.

The agent behavior can be controlled by the following options
which are set in cfg-file of the tests:

    samples=n
        specify number of attempts to redefine classes,
        10 by default

    interval=n
        specify sampling interval in milleseconds,
        100 by default

    package=xxx/yyy/zzz
        specify prefix used to filter the classes to be redefined,
        nsk/jvmti/scenarios/hotswap by default

    classes=n
        specify max number of classes to be redefined,
        100 by default

    mode=compiled|interpreted|mixed
        compiled - SingleStep is disabled,
        interpreted - SingleStep is enabled,
        mixed - enable/disable SingleStep after each redefining;
        compiled mode is used by default

    bci=emcp|call|alloc
        emcp - redefine classes with the same bytecodes,
        call - instrument method entries, alloc - instrument allocations;
        ecmp is used by default

    sync=n
        if = 0, redefine asynchronously from agent thread,
        if > 0, redefine synchronously within every n-th Exception event;
        0 by default

All the hotswap scenarios tests which use the agent in the mixed mode
occasionally crash. None of the other hotswap scenarios tests (which use
the agent in compiled or interpreted mode) crash.

Please note, that compiled, interpreted, or mixed mode of the agent
does not mean that VM is operated in compiled, interpreted, or mixed mode;
they are only agent's testing approaches (see the above list of options).

The crashes are not consistent, but happen very often in all the above
mention tests.

To reproduce the tests failure run doit.sh script in
GammaBase/Bugs/<this bug number>/<testname> directory:

    sh doit.sh <JAVA_HOME> <java_options>

The tests crash with:

(1) SIGSEGV or EXCEPTION_ACCESS_VIOLATION

    hs101t003: -client -Xcomp (linux)

    hs101t006: -client -Xcomp (linux)
               -server -Xcomp (sparcv9)

(2) assert(m->is_perm(),"bad methodOop in interpreter frame")
    at frame.cpp, 288

    hs101t003: -client -Xmixed (linux)
               -client -Xcomp (sparc, linux)
               -server -Xmixed (sparc, linux, win32)
               -server -Xcomp (sparc)

    hs101t006: -client -Xmixed (sparc, solx86, linux, win32)
               -client -Xcomp (sparc, solx86, linux, win32)
               -server -Xmixed (sparc, sparcv9, solx86, linux, win32)
               -server -Xcomp (sparc, sparcv9, solx86, linux, win32)

    hs102t002: -server -Xmixed (sparcv9)
               -server -Xcomp (sparcv9)

(3) Internal Error (4652414D453F53504152430E4350500211 01)
    that means frame_sparc.cpp, 529

    hs101t006: -client -Xcomp (sparc)
               -server -Xcomp (sparc)

    hs102t002: -client -Xmixed (sparc)
               -client -Xcomp (sparc)
               -server -Xmixed (sparc)
               -server -Xcomp (sparc)

(4) Error: only current thread can flush its registers
    at frame_sparc.cpp, 529

    hs101t003: -server -Xmixed (sparc)

    hs101t006: -server -Xint (sparc)

    hs102t002: -client -Xmixed (sparc)
               -client -Xcomp (sparc)

(5) assert(is_native() && bcp == code_base() || contains(bcp),"bcp doesn't belong to this method")
    at methodOop.cpp, 133

    hs101t003: -client -Xmixed (win32)
               -server -Xmixed (sparc)

(6) Internal Error (4E4D4554484F440E43505001BF)
    that means nmethod.cpp, 447

    hs102t002: -client -Xmixed (solx86, linux, win32)
               -server -Xmixed (solx86, linux, win32)

(7) Error: scope must be present
    at nmethod.cpp, 447

    hs102t002: -client -Xmixed (solx86, linux, win32)
               -server -Xmixed (solx86, linux, win32)

======================================================================

Comments
SUGGESTED FIX This fix is included in a batch of JFluid/RedefineClasses fixes targeted for a Tiger-Update release. See the jfluid-merge-update4-full-webrev.tar.Z attachment in 5088035 for the complete set of changes. ###@###.### 2005-2-25 22:32:30 GMT
25-02-2005

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mustang FIXED IN: mustang INTEGRATED IN: mustang
31-08-2004

EVALUATION Name: dd4877 Date: 07/15/2004 daniel.daugherty@Sun 2004-07-15 The NSK team has been developing new tests for the RedefineClasses() API. This bug is the first of what will likely be many new bugs submitted by the NSK team for this area. This is the natural consequence of applying focus and energy on an area that was lightly tested in the past. Addressing the robustness of the RedefineClasses() API along with some enhancements will be done in the post-Tiger time frame. The Tiger RC freeze is next week and there is simply no time for addressing the new failures revealed by these new tests. ====================================================================== I modified the test case and now it crashes without Redefine. Just calling enable/disable step event on a running java thread. So I modified the synopsis. Problem is jvmti is calling last_java_vframe() on a running java thread. Depending on the location where it is executing the thread may not be walkable and we should not call last_java_vframe() from jvmti if thread is not walkable. So fix for this is to call last_java_vframe() at safepoint. ###@###.### 2004-07-20
20-07-2004