JVM stürzt bei libzip.so

Mein JVM hält ständig abstürzt und unerwartet im libzip.also alle die Zeit. Ich habe eingereicht, der Fehler mit Oracle, aber entschieden, um zu sehen, ob jemand hier das problem und wenn ja, wie haben Sie damit umgehen? Dies ist eine web-app läuft ab

Linux-2.6.34-gentoo-r6 #1 SMP Fri Sep 24 00:15:06 CET 2010 i686 Intel(R) Xeon(R) CPU X5460 @ 3.16 GHz GenuineIntel GNU/Linux

Tomcat 7.0.14 mit jsvc.

Habe ich einen Schnappschuss von dem Bericht weiter unten. Seine standalone-server, niemand wird Zugriff auf alle tomcat-Glas oder andere Gläser während des Betriebs und seiner nicht gehostet von NFS.

 SIGSEGV (0xb) at pc=0xb6a72295, pid=19470, tid=241171312
JRE version: 6.0_29-b11  Java VM: Java HotSpot(TM) Server VM (20.4-b02 mixed mode linux-x86 )
Problematic frame:  C  [libzip.so+0x5295]  double+0x45
If you would like to submit a bug report, please visit:    http://java.sun.com/webapps/bugreport/crash.jsp  The crash happened outside the Java Virtual Machine in native code.  See problematic frame for where to report the bug.
---------------  T H R E A D  ---------------
Current thread (0x1044dc00):  JavaThread "catalina-exec-177" daemon [_thread_in_native, id=21423, stack(0x0e5af000,0x0e600000)]
siginfo:si_signo=SIGSEGV: si_errno=0, si_code=2 (SEGV_ACCERR), si_addr=0x10dfc000
Registers: EAX=0x10d00018, EBX=0xb6a7dabc, ECX=0x000fbfe6, EDX=0x00000000 ESP=0x0e5febf0, EBP=0x0e5fec18, ESI=0x0eadc098, EDI=0x10458800 EIP=0xb6a72295, EFLAGS=0x00010246, CR2=0x10dfc000
Top of Stack: (sp=0x0e5febf0) 0x0e5febf0:   b7869118 00000000 0ef2e648 b6a71216 0x0e5fec00:   13d1f690 10c492b0 0000bfe1 b6a7dabc 0x0e5fec10: 10458800 0ef2e648 0e5fec48 b6a7134d 0x0e5fec20:   10458800 00000004 0e5fec48 b77b727c 0x0e5fec30:   00000007 3d4af570 ffffffff b6a7dabc 0x0e5fec40:   31fe9ad0 1044dd20 0e5feca8 b6a6f585 0x0e5fec50:   0ef2e648 00000004 00000002 00000000 0x0e5fec60:   10b59810 3d5cff58 00000002 00004114
Instructions: (pc=0xb6a72295) 0xb6a72275:   05 01 00 00 0f 86 79 03 00 00 83 fa 02 76 41 8b 0xb6a72285:   57 40 8b 4f 50 8b 47 30 8b 77 38 d3 e2 8b 4f 64 0xb6a72295:   0f b6 44 01 02 31 c2 8b 47 4c 21 c2 8b 47 2c 89 0xb6a722a5:   57 40 21 c1 8b 47 3c 0f b7 04 50 89 45 f0 66 89
Register to memory mapping:
EAX=0x10d00018 is an unknown value EBX=0xb6a7dabc: <offset 0x10abc> in /usr/local/jdk1.6.0_29/jre/lib/i386/libzip.so at 0xb6a6d000 ECX=0x000fbfe6 is an unknown value EDX=0x00000000 is an unknown value ESP=0x0e5febf0 is pointing into the stack for thread: 0x1044dc00 EBP=0x0e5fec18 is pointing into the stack for thread: 0x1044dc00 ESI=0x0eadc098 is an unknown value EDI=0x10458800 is an unknown value
Stack: [0x0e5af000,0x0e600000],  sp=0x0e5febf0,  free space=318k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) C  [libzip.so+0x5295]  double+0x45 C  [libzip.so+0x434d]  double+0x10d C  [libzip.so+0x2585]  Java_java_util_zip_Deflater_deflateBytes+0x355 J  java.util.zip.Deflater.deflateBytes(J[BII)I
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code) J  java.util.zip.Deflater.deflateBytes(J[BII)I J  java.util.zip.GZIPOutputStream.finish()V J  org.apache.coyote.http11.Http11NioProcessor.actionInternal(Lorg/apache/coyote/ActionCode;Ljava/lang/Object;)V J  org.apache.coyote.http11.AbstractHttp11Processor.action(Lorg/apache/coyote/ActionCode;Ljava/lang/Object;)V J  org.apache.catalina.connector.Response.finishResponse()V J  org.apache.catalina.connector.CoyoteAdapter.service(Lorg/apache/coyote/Request;Lorg/apache/coyote/Response;)V J  org.apache.coyote.http11.Http11NioProcessor.process(Lorg/apache/tomcat/util/net/NioChannel;)Lorg/apache/tomcat/util/net/AbstractEndpoint$Handler$SocketState; J  org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run()V J  java.util.concurrent.ThreadPoolExecutor$Worker.run()V j  java.lang.Thread.run()V+11 v  ~StubRoutines::call_stub

Alle Hinweise dankbar.

  • Ich habe nicht gesehen, dieses Besondere problem, aber ich kann sagen, dass ich gesehen habe eine MENGE Probleme mit Java 6u29 bei der Arbeit. Menschen müssen 6 am Ende immer zurück datiert auf das Vorherige update, und diejenigen, die nicht erforderlich, um 6 gegangen, um 7u1 (die nicht nur scheint nicht zu haben keine Probleme in unserer Umwelt, ist aber deutlich schneller als 6).
  • geschieht dies, wenn Sie versuchen, einige Anwendungen?
  • Ihre beste option ist, um ein downgrade zu stable JRE-version.
  • Eigentlich habe ich immer auf aktualisieren, da war ich immer dieses problem seit der version 5. Es verlangsamt die Frequenz mit jedem upgrade. Sogar bis heute seine arbeiten, ohne ein problem für eine Woche, und dann, bam, abgestürzt, 3 mal schon. Ich bin ein bisschen vorsichtig, um ein upgrade auf 7, wie ich brauche, um zu bewerten, wie die app mit der neuesten Java-version, so dass Ihr nicht so schnell.
  • deaktivieren der gzip-Komprimierung von tomcat verwendet semi-hack zu tun den flush statt der Rollen eine Reine java-zip (habe ich geändert-code zu nutzen jzlib)
  • eine andere Sache zu prüfen, um zu sehen, wenn Sie versuchen, verwenden Sie eine 64-bit-Bibliothek auf einem 32-bit-Rechner, oder Umgekehrt.
  • java würde nicht begonnen haben, wenn nicht übereinstimmende
  • nur wenn die Bibliothek benötigt eine Referenz auf die JVM-Start nicht?
  • aber es funktioniert, es hat zu Dekomprimieren alle die Gläser in die bootstrap, es ist ein super-duper-core lib
  • Sie haben einen patch für tomcat 7 keine chance? Mach ich ein upgrade auf JDK7 um zu sehen, ob das problem weiterhin besteht.
  • Ist das auch Java-problem? Sollte ich nicht schauen Sie in libzip.so anstelle? Irgendwelche Gedanken...
  • es gibt keinen signifikanten Unterschied zwischen tomcat 6/7 in der coyote-adapter außer ich habe den code schreiben, der für den NIO-connector (im Grunde läuft tomcat6 coyote NIO-w/ catalina 5.5). Ich werde prüfen, Quelle tomcat7-und post - org.apache.coyote.http11.filters.GzipOutputFilter
  • Hier ist eine verrückte Vorschlag, versuchen memtest86 und sehen, wenn Sie schlechte RAM. memtest.org
  • xeon ' s laufen in der Regel auf ECC, also wäre das unwahrscheinlich.
  • es ist ein guter Vorschlag. Wir sind jedoch immer memtest Maschinen vor der Produktion und an dieser Stelle das Verfahren nicht erledigt werden können, dass schnell.
  • Naja, ein Upgrade auf JDK 7 hat nicht geholfen. Abgestürzt in einem anderen Ort: C [libzip.also+0x8324] deflate_slow+0x44 und siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x12400000

InformationsquelleAutor Daniil | 2011-12-06
Schreibe einen Kommentar