JDK-4646591 : mwevent001: debuggee VM crashes in -d64 -server mode
  • Type: Bug
  • Component: vm-legacy
  • Sub-Component: jvmdi
  • Affected Version: 1.4.1
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_8
  • CPU: sparc
  • Submitted: 2002-03-04
  • Updated: 2002-05-03
  • Resolved: 2002-04-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.
Other
1.4.1 hopperFixed
Related Reports
Relates :  
JDK-4692404 - com.sun.jdi.ClassType.invokeMethod causes a crash of debugee
Description

Name: dkR10014			Date: 03/04/2002



Testbase: testbase_nsk
Test:
 nsk/jdi/ModificationWatchpointEvent/_itself_/mwevent001


Platform: Solaris Sparc 2.8
Debuggee VM mode: -d64 -server

Debuggee error output:

debugee.stdout> 
debugee.stdout> Unexpected Signal : 11 occurred at PC=0xFFFFFFFF7D4AF41C
debugee.stdout> Function=[Unknown. Nearest: jio_vsnprintf+0x1399B8]
debugee.stdout> 
Library=/export/ld55/java/dest/jdk1.4.1-b03/solsparc/jre/lib/sparcv9/server/libj
vm.so
debugee.stdout> 
debugee.stdout> Current Java thread:
debugee.stdout> 
debugee.stdout> Dynamic libraries:
debugee.stdout> 0x100000000     
/export/ld55/java/dest/jdk1.4.1-b03/solsparc/jre/bin/sparcv9/java
debugee.stdout> 0xffffffff7f200000      /usr/lib/64/libthread.so.1
debugee.stdout> 0xffffffff7f400000      /usr/lib/64/libdl.so.1
debugee.stdout> 0xffffffff7ee00000      /usr/lib/64/libc.so.1
debugee.stdout> 0xffffffff7ed00000      
/usr/platform/SUNW,Ultra-60/lib/sparcv9/libc_psr.so.1
debugee.stdout> 0xffffffff7d000000      
/export/ld55/java/dest/jdk1.4.1-b03/solsparc/jre/lib/sparcv9/server/libjvm.so
debugee.stdout> 0xffffffff7ce00000      /usr/lib/64/libCrun.so.1
debugee.stdout> 0xffffffff7cb00000      /usr/lib/64/libsocket.so.1
debugee.stdout> 0xffffffff7c900000      /usr/lib/64/libnsl.so.1
debugee.stdout> 0xffffffff7c700000      /usr/lib/64/libm.so.1
debugee.stdout> 0xffffffff7d900000      /usr/lib/64/libw.so.1
debugee.stdout> 0xffffffff7c300000      /usr/lib/64/libmp.so.2
debugee.stdout> 0xffffffff7c100000      
/export/ld55/java/dest/jdk1.4.1-b03/solsparc/jre/lib/sparcv9/native_threads/libh
pi.so
debugee.stdout> 0xffffffff7be00000      
/export/ld55/java/dest/jdk1.4.1-b03/solsparc/jre/lib/sparcv9/libverify.so
debugee.stdout> 0xffffffff7bc00000      
/export/ld55/java/dest/jdk1.4.1-b03/solsparc/jre/lib/sparcv9/libjava.so
debugee.stdout> 0xffffffff7b900000      
/export/ld55/java/dest/jdk1.4.1-b03/solsparc/jre/lib/sparcv9/libzip.so
debugee.stdout> 0xffffffff2fe00000      
/usr/lib/locale/ru_RU.KOI8-R/sparcv9/ru_RU.KOI8-R.so.2
debugee.stdout> 0xffffffff2fc00000      
/export/ld55/java/dest/jdk1.4.1-b03/solsparc/jre/lib/sparcv9/libjdwp.so
debugee.stdout> 0xffffffff2f900000      
/export/ld55/java/dest/jdk1.4.1-b03/solsparc/jre/lib/sparcv9/libdt_socket.so
debugee.stdout> 0xffffffff2f700000      /usr/lib/64/nss_nisplus.so.1
debugee.stdout> 0xffffffff2f400000      /usr/lib/64/libdoor.so.1
debugee.stdout> 
debugee.stdout> Local Time = Mon Mar  4 11:36:06 2002
debugee.stdout> Elapsed Time = 3
debugee.stdout> #
debugee.stdout> # HotSpot Virtual Machine Error : 11
debugee.stdout> # Error ID : 4F530E43505002D5 01
debugee.stdout> # Please report this error at
debugee.stdout> # http://java.sun.com/cgi-bin/bugreport.cgi
debugee.stdout> #
debugee.stdout> # Java VM: Java HotSpot(TM) 64-Bit Server VM (1.4.1-beta-b03 
interpreted mode)
debugee.stdout> #
debugee.stdout> # An error report file has been saved as hs_err_pid1573.log.
debugee.stdout> # Please refer to the file for further information.
debugee.stdout> #
Dumping core...

To reproduce:
 1. cd /net/sqesvr.sfbay/export/vsn/GammaBase/Bugs/{this_bug_number}
 2. sh doit.sh <JAVA_HOME> -d64 -server

 where "-d64 -server" are optional parameters for debuggee VM mode.

This bug also affects another testbase_nsk test:
  nsk/jdi/WatchpointEvent/_itself_/wevent001
 
======================================================================

These tests also fail with same assertion:
nsk/jvmdi/events/fieldmod001
nsk/jvmdi/SetFieldModificationWatch/setfmodw005

The following test fail on solsparc 5.9 64b
nsk/jdi/ModificationWatchpointEvent/valueToBe/valuetobe001
nsk/jdi/ModificationWatchpointEvent/valueToBe/valuetobe002
nsk/jdi/WatchpointEvent/valueCurrent/valuecur001

Please check the bugs: 4651825,4664677
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: hopper FIXED IN: hopper INTEGRATED IN: hopper VERIFIED IN: hopper
14-06-2004
SUGGESTED FIX See the attached webrev
11-06-2004
PUBLIC COMMENTS .
10-06-2004
EVALUATION The problem appears to occur the code in void TemplateTable::putfield_or_static(int byte_no, bool is_static) seems to be passing something to InterpreterRuntime::post_field_modification in Gscratch2 that causes this assert in handles.cpp to fail: assert(obj->is_oop(), "sanity check"); ie, what is being passed isn't an oop. This putfield_or_static method (in file cpu/sparc/vm/templateTable_sparc.cpp) has an #ifdef _LP64... #else ....#endif which causes different values to be put into Gscratch2 in 32 and 64 bit modes. I changed the code so that the the #else part is always executed and the problem went away. --------------- It appears that the #ifdef _LP64 should not be there and instead the #else part should be used in both 32 and 64 bit modes, ie, 64 bit mode has one and two word values just like 32 bit mode does. The pop_l, pop_d functions confirm this. The testcase does modification watch point requests on all the data types. I removed the long and double types from the test and the test passed. Then I removed the #ifdef as described above and the original test passed. ###@###.### 2002-04-17
17-04-2002