xxxxx@xxxxx   2004-01-26

J2SE Version (please include all output from java -version flag):
  java version "1.5.0-beta"
  Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta-b32)
  Java HotSpot(TM) Client VM (build 1.5.0-beta-b32, mixed mode)

Does this problem occur on J2SE 1.3, 1.4 or 1.4.1?  Yes / No (pick one)
  No.

Operating System Configuration Information (be specific):
  RH Linux 9 + updates
  RH Linux 7.1 + updates
  Other Linux distributions (reported by customer, unverified)


Bug Description:
  VM crash with large heap sizes on Linux, but it works fine if 
  -Xshare:off is supplied with the VM startup options or if reduce the
  maximum heap size parameter (-Xmx) to 256m while even 384m maximum 
  heap size causes a failure. it could be reproduced on different
  with Debian GNU/Linux unstable as well (log file attached).

  The RH7.1/RH9 machines both run clean RPM installs of kernel, glibc,
  etc. No custom kernel, no patches, no custom compiled libraries. Just
  all  customer  updates.

  One observation which might or might not be important: All kernels where
  this occurs have highmem enabled (CONFIG_HIGHMEM4G=y). This seems to be
  the default for the latest RH kernels.

Steps to Reproduce (be specific):

matrix:~# chmod 755 j2sdk-1_5_0-beta-bin-b32-linux-i586-19_dec_2003.bin
matrix:~# ./j2sdk-1_5_0-beta-bin-b32-linux-i586-19_dec_2003.bin
[...type yes once for the license...]
matrix:~# ./j2sdk1.5.0/bin/java -version
java version "1.5.0-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0-beta-b32)
Java HotSpot(TM) Client VM (build 1.5.0-beta-b32, mixed mode)
matrix:~# ./j2sdk1.5.0/bin/java -Xmx512m -version
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  SIGSEGV (0xb) at pc=0x403effde, pid=2295, tid=1024
#
# Java VM: Java HotSpot(TM) Client VM (1.5.0-beta-b32 mixed mode)
# Problematic frame:
# V  [libjvm.so+0x2a3fde]
#
# An error report file with more information is saved as hs_err_pid2295.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Aborted
matrix:~#

use "-Xshare:off" to turn off sharing

or,

use "-XX:ThreadSafetyMargin=0" to disable stack-heap collision detection logic

The attached hs_err*.log file shows that VM fails to create an OSThread
object (likely due to OOM):

Instructions: (pc=0x40448fde)
0x40448fce:   46 1c 25 ff bf ff ff 89 46 1c 8b 86 84 00 00 00
0x40448fde:   c7 40 08 02 00 00 00 8b 46 1c a9 00 80 00 00 74 
;; 40448fce 46 1c
;; 40448fd0 25 ff bf ff ff          and    $0xffffbfff,%eax
;; 40448fd5 89 46 1c                mov    %eax,0x1c(%esi)
;; 40448fd8 8b 86 84 00 00 00       mov    0x84(%esi),%eax
;; ---------------
;; 40448fde c7 40 08 02 00 00 00    movl   $0x2,0x8(%eax)     <== %eax is NULL
;; 40448fe5 8b 46 1c                mov    0x1c(%esi),%eax
;; 40448fe8 a9 00 80 00 00          test   $0x8000,%eax
;; 40448fed 74 ff                   je     0x40448fee

Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x2a3fde] ;; os::start_thread(Thread*)+0x3e
V  [libjvm.so+0x303dd8] ;; Threads::create_vm(JavaVMInitArgs*)+0x318
V  [libjvm.so+0x184e72] ;; JNI_CreateJavaVM+0x62
nm: /usr/java/j2sdk1.5.0/bin/java: No such file or directory
C  [java+0x31dc]
C  [java+0x14df]
C  [libc.so.6+0x1562d]  __libc_start_main+0xa9

This is similar to 4779077. We should gracefully abort JVM if either
vm_thread or vm_thread->osthread() is not created due to OOM.

  xxxxx@xxxxx   2004-01-26

----------------------------

This crash can be reproduced only on fixed-stack LinuxThreads. For example,
on SuSE (or on Redhat with LD_ASSUME_KERNEL=2.2.5), one can see the crash by
doing:

1. java -Xshare:dump
2. java -Xmx512m -version

  xxxxx@xxxxx   2004-01-26

----------------------------

Further investigation reveals that it's not a simple out-of-memory error. There
are plenty of physical memory and virtual memory space left at the time of
crash. Instead, this crash is caused by a typo in os::reserve_memory():

      ... ...
      addr = (char*)::mmap(addr, bytes, PROT_READ|PROT_WRITE|PROT_EXEC,
                                 flags, -1, 0);
      ... ...
(**)  if (addr) {
        ... ...
        if ((address)addr > _highest_vm_reserved_address) {
          _highest_vm_reserved_address = (address)addr;
        }
      }

Note that mmap() returns MAP_FAILED, which is 0xffffffff, on failure. When
mmap() failed to reserve a memory region (this could happen when sharing is 
on and os::attempt_reserve_memory_at() couldn't find a place to map the 
shared archive), JVM will incorrectly record _highest_vm_reserved_address
to be 0xffffffff. This will cause the stack-heap collision detection code to
believe Java heap runs all the way to 0xffffffff, and any memory region 
between 0x0-0xffffffff can't be used as thread stack when running with fixed 
stack LinuxThreads. So creating VM thread will fail and eventually we have
the crash.

To get around the problem, one can either turn off sharing or disable
the stack-heap collision detection logic. Will fix in beta2, beta1 users
please see "workaround" section.

  xxxxx@xxxxx   2004-01-30

The 2004-01-30 explanation makes the most sense to me.  I'm
running debian/unstable with glibc 2.3.2 and kernel 2.6.4
(my dupped incident review id was 270420) which I'm pretty
sure is *not* a fixed-stack LinuxThreads (ie contrary to the
second 2004-01-26 comment).  Also I should not have been
out-of-memory, and aborting is *not* an adequate solution
(regardless of the first 2004-01-26 comment).

It seems that the mechanism described here would cause a
crash even if we're not using fixed stack LinuxThreads.