JDK-6426429 : crash when browsing to webapp/portlet URL while JAR file is being updated/reloaded
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util.jar
  • Affected Version: 2.0
  • Priority: P3
  • Status: Closed
  • Resolution: Duplicate
  • OS: solaris_9
  • CPU: sparc
  • Submitted: 2006-05-16
  • Updated: 2014-12-09
  • Resolved: 2006-08-01
Related Reports
Duplicate :  
JDK-4425695 - Updating jar files crashes running programs
Duplicate :  
JDK-8066951 - A fatal error has been detected by the Java Runtime Environment SIGSEGV
Relates :  
JDK-6236070 - Unexpected eeror in HotSpot VM. It got a SIGBUS.
Description
INFO: Reloading context [/portlet_jsf_admin]
#
# An unexpected error has been detected by HotSpot Virtual Machine:
#
#  SIGBUS (0xa) at pc=0xff3a0554, pid=27963, tid=13
#
# Java VM: Java HotSpot(TM) Server VM (1.5.0_04-b05 mixed mode)
# Problematic frame:
# C  [libc_psr.so.1+0x554]  memcpy+0x74
#
# An error report file with more information is saved as hs_err_pid27963.log
#
# If you would like to submit a bug report, please visit:
#   http://java.sun.com/webapps/bugreport/crash.jsp
#
Comments
EVALUATION Since there have been no updates to this bug in over 2 weeks, and it appears to be a duplicate, I'm closing it as such.
01-08-2006
EVALUATION Seems like a dup of the ancient and hard-to-fix 4425695: Updating jar files crashes running programs
12-07-2006
WORK AROUND Replacing in-use jar/zip files while the JVM is running is known to be problematic, and there are regular bugs filed about this. On Windows, the files are locked and replacing them is simply impossible. On Unix, the standard workaround is to RENAME the existing jar/zip files before moving the new ones into place. Hopefully any reference to the old files in the jar/zip code will use a fd to the old files. Don't do: cp foo.jar dir/. when there's an in-use dir/foo.jar
12-07-2006
EVALUATION -- The submitter duplicated the crash with mustang b88 (fastdebug). The comments section of the bug have a link to the core file. The crash is also in a memcpy but this time it's in zip code and there isn't any NIO code involved. One piece of information that is still missing is a description of what "Reloading context" means. In particular it would be very useful to know if this means that zip files are being replaced or updated in a running system. The two crashes observed so far (fatal error log from a 5.0u4 run and the latest using mustang-b88) have both involved reading from a zip file.
11-07-2006
EVALUATION The core file at cores.central does not seem to be available. We still don't have a reproducible test case. From a cursory examination of the copyToByteArray native code, it does not seem likely that the error is at at level. The pointers that are used for destination are provided by the VM via sun.misc.Unsafe. If those pointers are invalid, it is likely that memory corruption occurred earlier. A small reproducible test case would be required to track down such a problem because by the time the crash occurs, it's too late. Marking this bug incomplete until at least the core file is placed in an accessible space and we can re-visit whether more data is necessary.
10-07-2006
EVALUATION -- As Gary has noted, there isn't sufficient information in this bug report to diagnose this problem. Is it possible for the submitter to provide a description of what this "Reloading context" means? Does it involve updating zip files that are in use by the application? Is there a test environment anywhere that can be used to reproduce this issue? The error log attached to the bug report shows this stack: Stack: [0xd3e00000,0xd3e80000), sp=0xd3e7e7c8, free space=505k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C [libc_psr.so.1+0x554] memcpy+0x74 j java.nio.Bits.copyToByteArray(JLjava/lang/Object;JJ)V+0 j java.nio.Bits.copyToByteArray(JLjava/lang/Object;JJ)V+0 j java.nio.DirectByteBuffer.get([BII)Ljava/nio/ByteBuffer;+126 j java.util.zip.ZipFile$MappedZipFileInputStream.read([BII)I+53 v ~C2IAdapter J java.util.zip.InflaterInputStream.read([BII)I J org.apache.xerces.impl.XMLEntityManager$RewindableInputStream.read([BII)I : which suggests we have a bad pointer in the copyToByteArray native method. It's not clear yet how this can arise as there is a bounds check prior to the copy. The only interesting thing is that ZipFile$MappedZipFileInputStream.read is on the stack so this is a copy of an mmapped area to a byte array. It would be interesting if the submitter could do a test run with a recent mustang build to see if any issue manifests - this would be an interesting test because zip files are no longer mapped as they were in 5.0.
14-06-2006
EVALUATION Will be closing shortly.. Not able to reproduce without a testcase or steps.
13-06-2006
EVALUATION need access to this machine to replication of bug. Please provide steps to reproduce as well.
05-06-2006