United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6840196 NUMA allocator: crash in fastdebug during startup on Linux
JDK-6840196 : NUMA allocator: crash in fastdebug during startup on Linux

Details
Type:
Bug
Submit Date:
2009-05-12
Status:
Closed
Updated Date:
2011-01-19
Project Name:
JDK
Resolved Date:
2010-01-08
Component:
hotspot
OS:
linux
Sub-Component:
gc
CPU:
x86
Priority:
P2
Resolution:
Fixed
Affected Versions:
hs16
Fixed Versions:
hs16 (b03)

Related Reports
Backport:
Backport:
Backport:
Backport:

Sub Tasks

Description
During verification of fix for 6838842 we found that vm crashes in fastdebug mode on Fedora 10 and Suse 11.See comments on how to reproduce this.

in product mode it writes:
/net/sqenfs-1.sfbay/export1/comp/vm/jdk/hsx/16/pit/b03/jdk7b59/product/linux-amd64/bin/java
-XX:+UseNUMA -XX:+ForceNUMA -version


mbind: Invalid argument
mbind: Invalid argument
mbind: Invalid argument
mbind: Invalid argument
java version "1.7.0-ea"
Java(TM) SE Runtime Environment (build 1.7.0-ea-b57)
Java HotSpot(TM) 64-Bit Server VM (build
16.0-b03-2009-05-09-025354.et151817.hs16b03, mixed mode)

in fastdebug it crashes (actually, UseNuma is enough, which puzzles me):
/net/sqenfs-1.sfbay/export1/comp/vm/jdk/hsx/16/pit/b03/jdk7b59/fastdebug/linux-amd64/bin/java
-XX:+UseNUMA -XX:+ForceNUMA -version
VM option '+UseNUMA'
VM option '+ForceNUMA'
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007fb85fa0ea99, pid=31780, tid=140429896374608
#
# JRE version: 7.0-b57
# Java VM: Java HotSpot(TM) 64-Bit Server VM
(16.0-b03-2009-05-09-025354.et151817.hs16b03-fastdebug mixed mode
linux-amd64 )
# Problematic frame:
# C [libnuma.so.1+0x2a99]
#
# An error report file with more information is saved as:
# /import/gtee/hs_err_pid31780.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
#

                                    

Comments
EVALUATION

For some reason dlsym in Linux started to find the latest version of the 
symbol instead of the oldest, which I think it is supposed to do.
And since NUMA API in linux has changed in the 2.0 version of the 
library now we need to explicitly specify the version number of the 
symbol when running with this library. We also need to continue loading 
the base version of the symbols with the 1.0 version of the library.

The fix is to load NUMA API symbols in two stages. The first stage would 
try to load symbols with "libnuma_1.1" (the way they are in the >2.0 
versions). If that doesn't work the second stage loads them the normal way.

http://cr.openjdk.java.net/~iveresov/6840196/webrev.00
                                     
2009-05-12
SUGGESTED FIX

http://cr.openjdk.java.net/~iveresov/6840196/webrev.00
                                     
2009-05-12
EVALUATION

Approved for JDK 7 M3 build 59.
                                     
2009-05-12
EVALUATION

http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/cf71f149d7ae
                                     
2009-05-13



Hardware and Software, Engineered to Work Together