Bug ID: JDK-4925504 Vmark hang after 66 hours with 1.5.0-beta-b19 C2 on itanium2 with RH AS

Versions (Unresolved/Resolved/Fixed)

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.2_07 b01Fixed

It still hang on tiger_b25 with the same configuration
see details on http://jtgb4u4c.sfbay/itanium_bigapps/tiger_b25_itanium.html


sqa-big: Vmark hang after 66 hours with 1.5.0-beta-b19 C2 on itanium2 with RH AS2.1

JDK version
=============
java version "1.5.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta-b19)
Java HotSpot(TM) 64-Bit Server VM (build 1.5.0-beta-b19, mixed mode)

Platform
=============
Linux jtg-it4 2.4.20 #4 SMP Tue Jun 3 13:10:01 PDT 2003 ia64 unknown

Error message
=============
No error message, just hang with live process in memory.

Notes
=============
*We still keep the hanging process (Tomcat in this case) on above host and go /bt to check the test output.
*How to reproduce bug:
telnet to the hosts shown on the web for linux test machine with root/[host name] as id/passwd
goto /bt to execute script and /bs to get the running results
****take an example from jtg-it4 with vmark problem:****
telnet to jtg-it4 with root/jtg-it4 as id/passwd
execute /bs/runvmark.ksh -server
cd to /bt/xxx.xxx-server to get the results
###@###.### 2003-09-19
###@###.### 2003-10-27

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_07 tiger-beta FIXED IN: 1.4.2_07 tiger-beta INTEGRATED IN: 1.4.2_07 tiger-b31 tiger-beta VERIFIED IN: tiger-beta

23-09-2004

EVALUATION Looks like the test is running on B25 on testhost jtg-it6 Please update bug with status... This may have been addressed by latest Safepoint fix. ###@###.### 2003-10-23 VMARK hang again on jtg-it6. It looks like the glibc problem we encountered on Redhat 7.2 with Hopper a long time ago. The bug ID is 4656697 The glibc level on the machine is 2.2.4. It should be upgraded to 2.2.5. ###@###.### 2003-11-03 Got latest glibc for Itanium from Hui. We have upgraded the machines with glibc 2.2.9-32 ( Hui checked the sources and the fix for the glibc bug was in ). We will update bug report with build 27 status. ###@###.### 2003-11-04 With b27, vmark failed within 1 hour. ###@###.### 2003-11-06 I looked at a segv of vmark running on jtg-it7. The failure was a segv. in oops_interpreted_arguments_do called from C2IAdapter::preserve_callee_argument_oops. As I understand the problem the stack walking code assumes that a c2i adapter assumes that a c2i adapter frame looks identical to an interpreter frame. On ia64 this is not the case and it will lookup junk. We only very rarely will execute this path at a safepoint. The only way this can happen is if we safepoint after the c2iadapter tries to call the interpreter but before the interpreter takes possession of the arguments. There is only a single rare path for this to happen. That is the dreaded path in the interpreter frame setup where we call InterpreterRuntime::nmethod_entry_point. This particular path has been a pain in the past because we have set up an interpreter frame and must do the vm call using the caller's frame. In this case if the caller is a c2i adapter and we safepoint we are doomed. ###@###.### 2003-11-07

07-11-2003

Duplicate :	JDK-4925491 - Vtest hang after 5 days run on windows2003 itanium 64bits with C2 flag
Duplicate :	JDK-4925477 - sqa-big: ATG intermittent fail run on windows2003 itanium 64bits with C2 flag
Duplicate :	JDK-4933852 - Vmark intermittent fail run on windows2003 itanium 64bits with C2 flag