Description of problem: Ran a torrent program called azureus which I installed using yum. Just starting caused Java to crash. Version-Release number of selected component: java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc19 Additional info: reporter: libreport-2.1.10 backtrace_rating: 4 cmdline: /usr/lib/jvm/jre/bin/java -Xmx128m -cp /usr/lib64/eclipse/swt.jar:/usr/share/java/bcprov.jar:/usr/share/java/apache-commons-cli.jar:/usr/share/java/log4j.jar:/usr/share/azureus/Azureus2.jar:./Azureus2.jar -Djava.library.path=/usr/share/azureus -Dazureus.install.path=/usr/share/azureus -Dazureus.script=/bin/azureus -Dazureus.script.version=3 -Dorg.eclipse.swt.browser.UseWebKitGTK=true org.gudy.azureus2.ui.swt.Main crash_function: write_memory_serialize_page executable: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc19.x86_64/jre/bin/java kernel: 3.12.8-200.fc19.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #0 write_memory_serialize_page at /usr/src/debug/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc19.x86_64/openjdk/hotspot/src/share/vm/runtime/os.hpp:378 #1 transition at /usr/src/debug/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc19.x86_64/openjdk/hotspot/src/share/vm/runtime/interfaceSupport.hpp:156 #2 JavaCallWrapper::JavaCallWrapper at /usr/src/debug/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc19.x86_64/openjdk/hotspot/src/share/vm/runtime/javaCalls.cpp:73 #3 JavaCalls::call_helper at /usr/src/debug/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc19.x86_64/openjdk/hotspot/src/share/vm/runtime/javaCalls.cpp:403 #4 call at /usr/src/debug/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc19.x86_64/openjdk/hotspot/src/share/vm/runtime/javaCalls.cpp:320 #5 call_virtual at /usr/src/debug/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc19.x86_64/openjdk/hotspot/src/share/vm/runtime/javaCalls.cpp:217 #6 JavaCalls::call_virtual at /usr/src/debug/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc19.x86_64/openjdk/hotspot/src/share/vm/runtime/javaCalls.cpp:223 #7 thread_entry at /usr/src/debug/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc19.x86_64/openjdk/hotspot/src/share/vm/prims/jvm.cpp:2701 #8 JavaThread::thread_main_inner at /usr/src/debug/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc19.x86_64/openjdk/hotspot/src/share/vm/runtime/thread.cpp:1680 #9 JavaThread::run at /usr/src/debug/java-1.7.0-openjdk-1.7.0.60-2.4.4.0.fc19.x86_64/openjdk/hotspot/src/share/vm/runtime/thread.cpp:1660
Created attachment 854424 [details] File: backtrace
Created attachment 854425 [details] File: cgroup
Created attachment 854426 [details] File: core_backtrace
Created attachment 854427 [details] File: dso_list
Created attachment 854428 [details] File: environ
Created attachment 854429 [details] File: limits
Created attachment 854430 [details] File: maps
Created attachment 854431 [details] File: open_fds
Created attachment 854432 [details] File: proc_pid_status
Created attachment 854433 [details] File: var_log_messages
Is this reproducible?
Yes, the first time azureus runs it always crashs. It starts fine the next time (so whatever it's doing just that first time is causing Java to crash). There is an update, but I can hold off for now just in case it changes something.
I'm observing the same on F20. On my environment it's 100% reproducible. Steps to reproduce: $ rm -rf ~/.eclipse $ su -c 'echo -Djava.compiler=NONE >>/etc/eclipse.ini' $ ddd --args eclipse -clean (gdb) bt #0 0xb4948aa9 in write_memory_serialize_page (thread=0x834a000) at /usr/src/debug/java-1.7.0-openjdk-1.7.0.60-2.4.7.0.fc20.i386/openjdk/hotspot/src/share/vm/runtime/os.hpp:378 #1 transition (to=_thread_in_Java, from=_thread_in_vm, thread=0x834a000) at /usr/src/debug/java-1.7.0-openjdk-1.7.0.60-2.4.7.0.fc20.i386/openjdk/hotspot/src/share/vm/runtime/interfaceSupport.hpp:156 #2 JavaCallWrapper::JavaCallWrapper (this=0x81cc4ba4, callee_method=..., receiver=..., result=0x81cc4c64, __the_thread__=0x834a000) at /usr/src/debug/java-1.7.0-openjdk-1.7.0.60-2.4.7.0.fc20.i386/openjdk/hotspot/src/share/vm/runtime/javaCalls.cpp:73 #3 0xb494a3b0 in JavaCalls::call_helper (result=0x81cc4c64, m=0x81cc4c3c, args=0x81cc4c70, __the_thread__=0x834a000) at /usr/src/debug/java-1.7.0-openjdk-1.7.0.60-2.4.7.0.fc20.i386/openjdk/hotspot/src/share/vm/runtime/javaCalls.cpp:403 #4 0xb4a72696 in os::os_exception_wrapper (f=f@entry=0xb494a210 <JavaCalls::call_helper(JavaValue*, methodHandle*, JavaCallArguments*, Thread*)>, value=value@entry=0x81cc4c64, method=method@entry=0x81cc4c3c, args=args@entry=0x81cc4c70, thread=thread@entry=0x834a000) at /usr/src/debug/java-1.7.0-openjdk-1.7.0.60-2.4.7.0.fc20.i386/openjdk/hotspot/src/os/linux/vm/os_linux.cpp:4918 #5 0xb4949fcd in JavaCalls::call (result=result@entry=0x81cc4c64, method=..., args=args@entry=0x81cc4c70, __the_thread__=__the_thread__@entry=0x834a000) at /usr/src/debug/java-1.7.0-openjdk-1.7.0.60-2.4.7.0.fc20.i386/openjdk/hotspot/src/share/vm/runtime/javaCalls.cpp:320 #6 0xb49135f3 in instanceKlass::register_finalizer (i=i@entry=0x828cee88, __the_thread__=__the_thread__@entry=0x834a000) at /usr/src/debug/java-1.7.0-openjdk-1.7.0.60-2.4.7.0.fc20.i386/openjdk/hotspot/src/share/vm/oops/instanceKlass.cpp:702 #7 0xb493db3f in InterpreterRuntime::register_finalizer (thread=0x834a000, obj=0x828cee88) at /usr/src/debug/java-1.7.0-openjdk-1.7.0.60-2.4.7.0.fc20.i386/openjdk/hotspot/src/share/vm/interpreter/interpreterRuntime.cpp:233 #8 0xb26af1b8 in ?? () Full stack in attachment. java stack: for thread: "Start Level Event Dispatcher" daemon prio=10 tid=0x0834a000 nid=0x1de6 runnable [0x81cc4000] java.lang.Thread.State: RUNNABLE at java.lang.Object.<init>(Object.java:37) at java.io.InputStream.<init>(InputStream.java:45) at java.util.zip.ZipFile$ZipFileInputStream.<init>(ZipFile.java:659) at java.util.zip.ZipFile.getInputStream(ZipFile.java:356) - locked <0x828ce3f0> (a java.util.zip.ZipFile) at org.eclipse.osgi.baseadaptor.bundlefile.ZipBundleEntry.getInputStream(ZipBundleEntry.java:60) at org.eclipse.osgi.framework.internal.core.BundleURLConnection.connect(BundleURLConnection.java:53) - locked <0x828ced98> (a org.eclipse.osgi.framework.internal.core.BundleURLConnection) at org.eclipse.osgi.framework.internal.core.BundleURLConnection.getInputStream(BundleURLConnection.java:99) at java.net.URL.openStream(URL.java:1037) at org.eclipse.osgi.internal.baseadaptor.AdaptorUtil.loadManifestFrom(AdaptorUtil.java:191) at org.eclipse.core.runtime.internal.adaptor.EclipseStorageHook.getGeneratedManifest0(EclipseStorageHook.java:410) at org.eclipse.core.runtime.internal.adaptor.EclipseStorageHook.getGeneratedManifest(EclipseStorageHook.java:397) at org.eclipse.core.runtime.internal.adaptor.EclipseStorageHook.createCachedManifest(EclipseStorageHook.java:392) at org.eclipse.core.runtime.internal.adaptor.EclipseStorageHook.getManifest(EclipseStorageHook.java:517) at org.eclipse.osgi.internal.baseadaptor.BaseStorage.loadManifest(BaseStorage.java:322) at org.eclipse.osgi.internal.baseadaptor.BundleInstall.begin(BundleInstall.java:82) at org.eclipse.osgi.framework.internal.core.Framework.installWorkerPrivileged(Framework.java:941) at org.eclipse.osgi.framework.internal.core.Framework$1.run(Framework.java:845) at org.eclipse.osgi.framework.internal.core.Framework$1.run(Framework.java:1) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.Framework.installWorker(Framework.java:904) at org.eclipse.osgi.framework.internal.core.Framework.installBundle(Framework.java:840) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.installBundle(BundleContextImpl.java:137) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.installBundle(BundleContextImpl.java:131) at org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.installBundles(ConfigApplier.java:197) at org.eclipse.equinox.internal.simpleconfigurator.ConfigApplier.install(ConfigApplier.java:89) at org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:182) - locked <0x8d2a0190> (a java.lang.Object) at org.eclipse.equinox.internal.simpleconfigurator.SimpleConfiguratorImpl.applyConfiguration(SimpleConfiguratorImpl.java:196) - locked <0x8d2a0190> (a java.lang.Object) at org.eclipse.equinox.internal.p2.reconciler.dropins.ProfileSynchronizer.applyConfiguration(ProfileSynchronizer.java:820) at org.eclipse.equinox.internal.p2.reconciler.dropins.ProfileSynchronizer.synchronize(ProfileSynchronizer.java:147) at org.eclipse.equinox.internal.p2.reconciler.dropins.Activator.synchronize(Activator.java:468) - locked <0x8d98f8f0> (a java.lang.Class for org.eclipse.equinox.internal.p2.reconciler.dropins.Activator) at org.eclipse.equinox.internal.p2.reconciler.dropins.Activator.start(Activator.java:176) at org.eclipse.osgi.framework.internal.core.BundleContextImpl$1.run(BundleContextImpl.java:711) at java.security.AccessController.doPrivileged(Native Method) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.startActivator(BundleContextImpl.java:702) at org.eclipse.osgi.framework.internal.core.BundleContextImpl.start(BundleContextImpl.java:683) at org.eclipse.osgi.framework.internal.core.BundleHost.startWorker(BundleHost.java:381) at org.eclipse.osgi.framework.internal.core.AbstractBundle.resume(AbstractBundle.java:390) at org.eclipse.osgi.framework.internal.core.Framework.resumeBundle(Framework.java:1176) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:559) at org.eclipse.osgi.framework.internal.core.StartLevelManager.resumeBundles(StartLevelManager.java:544) at org.eclipse.osgi.framework.internal.core.StartLevelManager.incFWSL(StartLevelManager.java:457) at org.eclipse.osgi.framework.internal.core.StartLevelManager.doSetStartLevel(StartLevelManager.java:243) - locked <0x8d248e50> (a java.lang.Object) at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:438) at org.eclipse.osgi.framework.internal.core.StartLevelManager.dispatchEvent(StartLevelManager.java:1) at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340) Installed versions of eclipse and openjdk: $ rpm -qa | grep eclipse | sort eclipse-anyedit-2.4.2-4.fc20.noarch eclipse-cdt-8.2.1-3.fc20.i686 eclipse-cmakeed-1.1.6-6.fc20.noarch eclipse-debuginfo-4.3.2-3.fc20.i686 eclipse-ecf-core-3.8.0-1.fc20.noarch eclipse-emf-2.9.2-1.fc20.noarch eclipse-emf-core-2.9.2-1.fc20.noarch eclipse-equinox-osgi-4.3.2-3.fc20.i686 eclipse-jdt-4.3.2-3.fc20.i686 eclipse-platform-4.3.2-3.fc20.i686 eclipse-rse-3.5-3.fc20.noarch eclipse-swt-4.3.2-3.fc20.i686 icu4j-eclipse-50.1.1-2.fc20.noarch $ rpm -qa | grep openjdk-1.7 | sort java-1.7.0-openjdk-1.7.0.60-2.4.7.0.fc20.i686
Created attachment 887767 [details] backtrace
I've also tried to run eclipse using jdk-1.8.0 but it crashes as described in bug 979491, comment 9.
I don't currently reproduce either crash (azureus or eclipse). Package versions: java-1.7.0-openjdk-1.7.0.65-2.5.1.2.fc19.x86_64 azureus-5.0.0.0-6.fc19.noarch eclipse-cdt-8.2.1-3.fc19.x86_64 eclipse-cdt-parsers-8.2.1-3.fc19.x86_64 eclipse-dtp-1.11.1-1.fc19.noarch eclipse-ecf-core-3.6.1-1.fc19.noarch eclipse-emf-2.9.1-1.fc19.noarch eclipse-emf-core-2.9.1-1.fc19.noarch eclipse-emf-xsd-2.9.1-1.fc19.noarch eclipse-equinox-osgi-4.3.1-5.fc19.x86_64 eclipse-gef-3.9.1-0.2.gitb9f2e9.fc19.noarch eclipse-jdt-4.3.1-5.fc19.x86_64 eclipse-jgit-3.1.0-1.fc19.noarch eclipse-linuxtools-2.1.0-3.fc19.noarch eclipse-m2e-core-1.4.0-3.fc19.noarch eclipse-manpage-2.1.0-3.fc19.noarch eclipse-p2-discovery-4.2.1-2.fc19.noarch eclipse-pde-4.3.1-5.fc19.x86_64 eclipse-platform-4.3.1-5.fc19.x86_64 eclipse-ptp-7.0.4-1.fc19.x86_64 eclipse-ptp-rdt-7.0.4-1.fc19.noarch eclipse-ptp-rdt-xlc-7.0.4-1.fc19.noarch eclipse-rse-3.5-1.fc19.noarch eclipse-swt-4.3.1-5.fc19.x86_64 eclipse-swtbot-2.1.0-1.fc18.noarch eclipse-systemtap-2.1.0-3.fc19.noarch eclipse-wtp-common-3.5.1-1.fc19.noarch eclipse-wtp-servertools-3.5.1-1.fc19.noarch eclipse-wtp-sourceediting-3.5.1-1.fc19.noarch icu4j-eclipse-50.1.1-1.fc19.noarch Do either of you still experience this crash with latest updates?
Installed azureus again and just tried it. No problems. This is still on a Fedora 19 system. FYI, azureus has been replaced by vuze, so I hadn't run azureus recently.
Thanks Adam. Yeah, I don't generally use azureus or vuze myself but I'd heard about the (not exactly recent) azureus->vuze thing. Either way if it was still exposing a JVM bug we'd want to address it :) I'm going to close this bug. Damian, if you are still experiencing those Eclipse crashes I'd have to assume a different root cause, so it would be appropriate to report separately.