JDK-6840196 : NUMA allocator: crash in fastdebug during startup on Linux
  • Type: Bug
  • Component: hotspot
  • Sub-Component: gc
  • Affected Version: hs16
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2009-05-12
  • Updated: 2011-01-19
  • Resolved: 2010-01-08
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.
JDK 6 JDK 7 Other
6u14pFixed 7Fixed hs15Fixed
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 http://hg.openjdk.java.net/jdk7/hotspot/hotspot/rev/cf71f149d7ae
13-05-2009
EVALUATION Approved for JDK 7 M3 build 59.
12-05-2009
SUGGESTED FIX http://cr.openjdk.java.net/~iveresov/6840196/webrev.00
12-05-2009
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
12-05-2009