-
Bug
-
Resolution: Fixed
-
P4
-
6
-
mustang
-
generic, sparc, itanium
-
generic
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2123746 | 5.0u4 | Daniel Daugherty | P3 | Resolved | Fixed | b02 |
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)
======================================================================
- backported by
-
JDK-2123746 enabling/disabling of SingleStep on a running java thread causes crash
- Resolved
- duplicates
-
JDK-5008590 enabling single step on non-walkable thread crashes (sparc, ia64)
- Closed