JDK-6348968 : Jvm(B53+) crash on Redhat Linux AS4 after dlopen("libgnomevfs-2.so.0")
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 6
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: linux_redhat_4.0
  • CPU: generic,x86
  • Submitted: 2005-11-11
  • Updated: 2012-10-08
  • Resolved: 2005-11-30
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
6 b62Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Description
dlopen("libgnomevfs-2.so.0")  will cause jvm crash on Redhat AS4 when the java application exits. It can reproduce always using mustang b53+ on Redhat AS4. 

If we replaced the client/libjvm.so of b53 , it worked.
So it might be hotspot's problem on linux.
See 6336247 for details.

To reproduce the problem, compile and run the following T.java with mustang b53+.
import java.awt.*;
public class T
{
  public static void main(String[] args){
   System.out.println(Desktop.getDesktop().isDesktopSupported(); //dlopen libgnomevfs-2.so
  }
}

Jvm will crash after running "java T" .

The printed stack trace shows it crashed at libc's exit() function:

#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  SIGSEGV (0xb) at pc=0x00001e62, pid=13223, tid=3051248560
#
# Java VM: Java HotSpot(TM) Client VM (1.6.0-ea-b55 mixed mode, sharing)
# Problematic frame:
# C  0x00001e62
...
Stack: [0xb5d65000,0xb5de6000),  sp=0xb5de4d5c,  free space=511k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
C  0x00001e62       ---> It's "_fini() in exit()"  using java -XX:OnError="pstack %p"
C  [librt.so+0x6dd6]
C  [ld-linux.so.2+0xc887]
C  [libc.so.6+0x2a467]  exit+0x77
V  [libjvm.so+0x372bfd]
V  [libjvm.so+0x372117]
V  [libjvm.so+0x3718fc]
V  [libjvm.so+0x371abf]
V  [libjvm.so+0x3716ff]
V  [libjvm.so+0x2ccdb3]
C  [libpthread.so.0+0x5341]

VM_Operation (0xb533f740): exit, mode: safepoint, requested by thread 0x08481a00
...

Comments
EVALUATION This bug was fun. For not exactly clear to me reasons, if we trying to dynamically link librt.so into the main image (when trying to get high resolution timer routines in os::Linux::clock_init()) it fails to do so. LD_DEBUG=all gives 13270: /usr/lib/librt.so: error: relocation error: symbol __librt_multi ple_threads, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference (fatal) And in fact dynamical linker tries to load different images: -rwxr-xr-x 1 root 47724 Nov 4 05:34 /lib/librt-2.3.6.so* ^^ on dlopen("librt.so") -rwxr-xr-x 1 root 48820 Nov 4 05:34 /lib/tls/librt-2.3.6.so* ^^ on dlopen("librt.so.1") And it seems, during cleanup of failed attempt to map wrong librt.so we fail to unregister one of __fini finalizers, later reused by succeeded load of librt.so. And on exit we trying to execute this finalizer - and go boom. Swapping of dlopens - and making dlopen("librt.so.1") first fixes the problem.
14-11-2005

SUGGESTED FIX *** /tmp/geta15662 2005-11-14 18:50:46.145671707 +0300 --- os_linux.cpp 2005-11-14 18:49:24.525387257 +0300 *************** *** 1183,1191 **** #endif void os::Linux::clock_init() { ! void* handle = dlopen("librt.so", RTLD_LAZY); if (handle == NULL) { ! handle = dlopen("librt.so.1", RTLD_LAZY); } if (handle) { --- 1183,1191 ---- #endif void os::Linux::clock_init() { ! void* handle = dlopen("librt.so.1", RTLD_LAZY); if (handle == NULL) { ! handle = dlopen("librt.so", RTLD_LAZY); } if (handle) {
14-11-2005