FULL PRODUCT VERSION :
java version "1.6.0-beta2"
Java(TM) SE Runtime Environment (build 1.6.0-beta2-b85)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0-beta2-b85, mixed mode)


FULL OS VERSION :
Linux tidore 2.6.16-gentoo-r7 #1 SMP Thu May 11 10:45:35 CEST 2006 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ GNU/Linux


A DESCRIPTION OF THE PROBLEM :
When I try to debug an application using Eclipse 3.2RC5 (x86_64), the new JVM that is started to run the application crashes immediately during initialization. This happens regardless of which application I'm trying to debug.


THE PROBLEM WAS REPRODUCIBLE WITH -Xint FLAG: No

THE PROBLEM WAS REPRODUCIBLE WITH -server FLAG: Yes

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Method 1: simply run this command line (with or without a class name):

java -agentlib:jdwp=transport=dt_socket,suspend=y,address=localhost:60652

Method 2: Create trivial application in Eclipse (3.2RC5, x86_64). Hit Debug button (Shift-Alt-J D).

EXPECTED VERSUS ACTUAL BEHAVIOR :
Expected result: no errors.
Actual result: JVM abort with hs_err_pid#.log file copied below.
ERROR MESSAGES/STACK TRACES THAT OCCUR :
#
# An unexpected error has been detected by Java Runtime Environment:
#
# Internal Error (494E5445525052455445520E4350500144), pid=30361, tid=1076017504
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.6.0-beta2-b85 mixed mode)
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#


REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Run the 32 bit x86 version of the JDK (and Eclipse), where the problem does not occur.
The following test is failed as well because of this bug:
  nsk/jvmti/AddCapabilities/addcaps003

It happens on the Linux amd64 applebee machine:
ss45998@applebee uname -a
Linux applebee 2.6.16-8-default #1 Tue Mar 28 11:00:06 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux

ss45998@applebee cat /proc/version
Linux version 2.6.16-8-default (geeko@buildhost) (gcc version 4.1.0 (SUSE Linux)) #1 Tue Mar 28 11:00:06 UTC 2006

BTW the test is passed on the Linux amd64 machine quoddy:
ss45998@quoddy uname -a
Linux quoddy 2.4.19-SMP #1 SMP Thu Jul 17 21:37:10 UTC 2003 x86_64 unknown

ss45998@quoddy cat /proc/version
Linux version 2.4.19-SMP (###@###.###) (gcc version 3.2.2 (SuSE Linux)) #1 SMP Thu Jul 17 21:37:10 UTC 2003

Obviously there is some difference in the two machines architectures, so the
generated codelets sizes on them are different.
Dan and I still wonder what is this difference?
Also, please, see a fragment from the hs_err log file:

ss45998@applebee hs_err hs_err_pid27450.log | c++filt
#
# An unexpected error has been detected by Java Runtime Environment:
#
# Internal Error (494E5445525052455445520E4350500144), pid=27450, tid=1076017488;;
;; Error ID is
;; interpreter.cpp, 324
#
# Java VM: Java HotSpot(TM) 64-Bit Server VM (1.6.0-beta2-b86 mixed mode)
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#

--------------- T H R E A D ---------------

Current thread (0x0000000040111c00): JavaThread "Unknown thread" [_thread_in_vm, id=27451]

Stack: [0x000000004012b000,0x000000004022c000), sp=0x000000004022a670, free space=1021k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [libjvm.so+0x5ee53f];; VMError::report_and_die()+0x23f
V [libjvm.so+0x2323a6];; report_fatal(char const*, int, char const*)+0x46
V [libjvm.so+0x2cdefe];; CodeletMark::codelet_size()+0x4e
V [libjvm.so+0x2ccfd0];; AbstractInterpreterGenerator::set_entry_points(Bytecodes::Code)+0x80
V [libjvm.so+0x2cc8e4];; AbstractInterpreterGenerator::generate_all()+0x2bc4
V [libjvm.so+0x2f22fc];; InterpreterGenerator::InterpreterGenerator(StubQueue*)+0x1c
V [libjvm.so+0x2c9426];; AbstractInterpreter::initialize()+0xb6
V [libjvm.so+0x2c97d1];; interpreter_init()+0x11
V [libjvm.so+0x2a8065];; init_globals()+0x45
V [libjvm.so+0x5b70c8];; Threads::create_vm(JavaVMInitArgs*, bool*)+0x208
V [libjvm.so+0x32570d];; JNI_CreateJavaVM+0x7d


But the VM does not print the Interpreter sizes when it is crashed,
so it is hard to tell how much lack of space is in this case.
So, probably, it would be nice to fix a lack of diagnostics for this code path.

The test is passed on the Linux amd64 machine quoddy.
It prints the following info and additional details (skipped here) for each codelet:

  #----------------------------------------------------------------------
  #Interpreter
  #
  #code size = 148K bytes
  #total space = 159K bytes
  #wasted space = 11K bytes
  #
  ## of codelets = 254
  #avg codelet size = 598 bytes