The Notepad demo will crash during shutdown with JDK-1.5 b08 on Redhat 9.

An unexpected exception has been detected in native code outside the VM.
Unexpected Signal : 11 occurred at PC=0x42073770 during VM shutdown
Function=__libc_free+0x70
Library=/lib/tls/libc.so.6
[...]
#
# The exception above was detected in native code outside the VM
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0-beta-b08 mixed mode)
#
# An error report file has been saved as hs_err_pid4893.log.
# Please refer to the file for further information.
#

It happens everytime.

System information:

fez:~> uname -a
Linux fez.sfbay. xxxxx .com 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003 i686 i686 i386
GNU/Linux
fez:~> rpm -q glibc
glibc-2.3.2-27.9

Note that b08 is compiled by gcc-3.2.1.



  xxxxx@xxxxx   2003-11-05
This bug is still reproducible with j2sdk 1.5.0 b26.

N/A

This bug is filed to document a known issue of Redhat 9. Please see Redhat
bugzilla:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=90301

The problem only happens when running a gcc-3.2-built JDK with NPTL. As
tiger is being built by gcc-3.2, and NPTL is the default library on RH-9,
people are likely to see this crash in the near future.

The problem has been fixed in NPTL in late April, but the change has not
shown up in Redhat glibc patches. Before the fix is published on redhat
errata site (http://www.redhat.com/errata), here are two possible solutions:

1. set LD_ASSUME_KERNEL to 2.4.1, it will disable NPTL. JDK will be running
   with LinuxThreads.

2. get the latest glibc development snapshot from redhat rawhide. I tested
   glibc-2.3.2-57, and it works fine.

We can't fix or get around the problem in JDK, so I'm closing it as will-not-fix

  xxxxx@xxxxx   2003-06-27



Since this isn't really an "unexpected bug" anymore - we
know that it happens and why it happens -, the J2RE should produce a
better error message that  explains how to correct the situation, either
directly or by reference to a web page. According to   xxxxx@xxxxx  ,
the cause can be identified by checking the pthread version inside the
signal handler.

Other options considered but rejected in an email discussion were to
check the OS during installation (doesn't work for the case of an
installation shared by multiple machines) or during JVM startup (non-GUI
applications will generally not run into this problem).
======================================================================

This bug is causing testing problem on RedHad 9.0, regression test will all failed with crashes. This (and workaround) need to be documented somewhere and need to be made aware to people who are running test or applications.
The crashes happened in Tiger build 26 and the PIT build.

  xxxxx@xxxxx   2003-11-03

======================================================================

See also 4938816. We now believe this bug and 4938816 are due to the
same gcc problem - all dynamic libraries share the same __dso_handle,
so when a DSO is unloaded, dlclose() improperly calls the clean-up 
method of _all_ DSO.

In 4938816, it caused a crash in compiler thread; in this bug, exit()
will unload DSO one by one, it's very likely the clean-up method of some DSO 
is called more than once, so it tries to free the same object twice, causing 
a crash in __libc_free.

The fix for 4938816 is to build gcc with a newer binutils package. Using
that gcc to build JDK,   xxxxx@xxxxx   has verified that it also 
fixes this bug.

  xxxxx@xxxxx   2003-11-05

=====================================================================

Redhat finally released a glibc update that can avoid the crash:

https://rhn.redhat.com/network/errata/details/index.pxt?eid=1876

In addition to the fix of this __libc_free+0x70 crash (note: we now
know that the real problem lies in gcc and the fix is to build gcc with new 
binutils), this update contains another important NPTL change to fix
intermittent pthread_cond_broadcast hangs. The hang was observed during
bigapp tests. It's recommended to apply the glibc patch if you are
using Redhat 9.

  xxxxx@xxxxx   2003-11-12

=====================================================================

Starting from 1.5-b42, JDK 1.5 is compiled with gcc-3.2.1-7a, which is
exactly the same as gcc-3.2.1-7, but built with an updated binutils
(see 4938816). This has fixed the crash on Redhat 9. I'm closing this
bug as a dup of 4963403, as the compiler change was integrated with
that bug id.

  xxxxx@xxxxx   2004-03-12

This problem is reported as fixed in glibc-2.3.2-27.9.4
I just ran update2date and got glibc-2.3.2-27.9.7 and 
that fixed this problem. 

To help to identify the scope of this problem:

This very trivial AWT program causes this problem (no 
X11 display required):

public class HelloLabelApp {
 public static void main(String argv[]) {
  java.awt.Container c = new java.awt.Container();
 }
}

On Redhat 9 (Linux linuxpc 2.4.20-8 #1 Thu Mar 13 
17:54:28 EST 2003 i686 i686 i386 GNU/Linux), you 
can avoid the problem with even the previous minor 
version:

export LD_ASSUME_KERNEL=2.4.19

will avoid the problem.

Other major vendors have this problem, such as 
Oracle's Database Configuration Assistant "dbca" 
program.

The RedHat bug identifies the cxa_atexit() routine as 
the crux of the problem.  In the hs_err_pidXXXXX.log 
file that the current JDK 1.5 beta produces, 
another "cxa" routine appears.  It looks something like:

Stack: [0xbfe00000,0xc0000000),  sp=0xbfffdde0,  free 
space=2039k
Native frames: (J=compiled Java code, j=interpreted, 
Vv=VM code, C=native code)
C  [libc.so.6+0x734c0]  __libc_free+0x70
C  [libc.so.6+0xeb85e]
C  [libc.so.6+0x29eae]  __cxa_finalize+0x7e
C  [libawt.so+0x1337c]
C  [libawt.so+0x6d92d]
C  [ld-linux.so.2+0xc894]
C  [libc.so.6+0x29c20]  exit+0x70
C  [libc.so.6+0x155d8]

At a note: cxa_atexit() is documented as "atexit 
equivalent function for new C++ ABI".

For the curious: NPTL stands for "Native POSIX Thread 
Library".

http://people.redhat.com/drepper/nptl-design.pdf

There is also a possible fix on the JDK side, which we will
apply for beta2 (it's too late that we didn't make the beta1
cut-off date). 1.5 beta2 should work fine on vanilla Redhat 9
without problem.