memcpy crash

[Rijk]

What I expected: normal application running
What happened instead (copy-paste from console; includes package versions):
#
# An unexpected error has been detected by Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xb7dc69bc, pid=11999, tid=3029109648
#
# Java VM: OpenJDK Client VM (1.6.0-b09 mixed mode, sharing linux-x86)
# Problematic frame:
# C [libc.so.6+0x739bc] memcpy+0x1c
#
# An error report file with more information is saved as:
# /home/rijk/xldoc/deploy/hs_err_pid11999.log
#
# If you would like to submit a bug report, please visit:
# https://bugs.launchpad.net/ubuntu/+source/openjdk-6/
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
Aborted

release of Ubuntu (from hs_err_pid11999.log):
OS:Ubuntu 8.04 (hardy)
uname:Linux 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686
libc:glibc 2.7 NPTL 2.7

[Matthias Klose (doko)]

- is this reproducible in intrepid?
- could you provide a test case to reproduce the crash?

[Rijk (r-j-c-vanhaaften-deactivatedaccount)]

> - is this reproducible in intrepid?
This is not even deterministically reproducible on my own machine(s).
It happened only a few times, up to now.

But due to the fact that the error occurs outside the Java VM, I
decided to report it nonetheless.

> - could you provide a test case to reproduce the crash?
As stated above: I'm sorry, I can't (or at least: I didn't manage
until now.) The problem is occurring in a large long-running
application with a memory usage above 100MB.

If I manage to track down the problem (or otherwise am able to
provide more, useful information) I will definitely do so. But
at the moment, I really have no clue about how to get an isolated
deterministic minimal case.

I did however report the error because
* the error occurred more than once
* the application crashing the VM is pure-java, so the code as-is
 cannot directly cause a crash outside the VM due to some programming bug.
* I hope that I will manage to track it down one day or
 that other users submit bug-reports that can be linked to this one.

>This bug report will be marked for expiration in 59 days if no further activity occurs.
I really wonder why difficult bugs are scheduled for removal this soon. It would really
be sad if due to the fact that this bug is going to be expired without being resolved
would force me to abandon open-jdk (just because I cannot afford the downtime due
to unexpected crashes).

[Rijk (r-j-c-vanhaaften-deactivatedaccount)]

The crash did occur serveral times now. It only appears on classloading (see log) and is probably caused by GetEntry in libzip:
C [libzip.so+0x4a39] ZIP_GetEntry+0xa9
C [libzip.so+0x3659] Java_java_util_zip_ZipFile_getEntry+0x139
This very much looks like
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6366468
which is also reported against Java 1.6, though there is a report that the "Same bug is there on JDK 1.5"
>Submitter replied that it's very unlikely due to updating jar files crashes running programs.
That also applies to me: No jars are being altered while the program runs.

This suggests that the bug is old (reported as early as 22 dec 2005), consistently closed while not fixed ("Priority: 5-Very Low", "State 11-Closed, Not Reproducible, bug") and probably still present in Java's libzip. Moreover, the bug is platform independent (reported on Ubuntu i386 and Solaris SPARC at least).

>The problem is clearly happening in the ZIP_GetEntry method.
Maybe it should be assigned to the ZIP team for further evaluation and action.

[Rijk (r-j-c-vanhaaften-deactivatedaccount)]

After a long time of testing, the problem appears to occur only if multiple (java-) processes access one jar file concurrently. I'm still not sure whether both are just reading or (which seems more probable) one of them tries to write something.

[Rijk (r-j-c-vanhaaften-deactivatedaccount)]

The problem is still biting me, but it
* happens not only on OpenJDK but also happens on the Sun JDK (which are available as different packages on Ubuntu)
* only happens while Netbeans is running (when I switch to a simple text editor and use ant from the console for compiling, the problem cannot be reproduced)

[Matthias Klose (doko)]

please upgrade to b11 (found in hardy-updates) or b12 (intrepid) and report back.

[Rijk (r-j-c-vanhaaften-deactivatedaccount)]

Hi Matthias,

> please upgrade to b11 (found in hardy-updates) or b12 (intrepid) and
> report back.
I upgraded to b11 and will try again.

Thanks for your support,

Rijk van Haaften

[robogeek (david-herron-sun)]

There's a longstanding known issue that if a jar file used by an application is modified while the application is running then the java VM will crash.

<i>the problem appears to occur only if multiple (java-) processes access one jar file concurrently. I'm still not sure whether both are just reading or (which seems more probable) one of them tries to write something.</i>

[Rijk (r-j-c-vanhaaften-deactivatedaccount)]

I have been using b11 for some time now, and the VM no longer crashes. Instead, I sometimes get an exception from the ClassLoader (which is perfectly ok and indeed what I expected). I think this issue can be closed as fixed.

[Matthias Klose (doko)]

thanks for checking. closing the report