Description of problem: When proprietary sun jvm is selected as alternative, it is impossible to run azureus. As soon as its main window opens up, the following crash occurs: [xxx@xxx ~]$ azureus # # An unexpected error has been detected by HotSpot Virtual Machine: # # Internal Error (53484152454432554E54494D450E43505001A3), pid=9185, tid=3086871424 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_09-b01 mixed mode, sharing) # An error report file with more information is saved as hs_err_pid9185.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # /usr/bin/azureus: line 18: 9185 Aborted LD_LIBRARY_PATH=/usr/lib/eclipse:/usr/lib CLASSPATH=/usr/share/java/gcj-endorsed/bcprov-1.33.jar:`build-classpath jakarta-commons-cli log4j swt-gtk-3.2 gtk2.8 glib0.2`:/usr/share/azureus/Azureus2.jar java -Dgnu.gcj.runtime.VMClassLoader.library_control=never -Dazureus.install.path=$APPDIR org.gudy.azureus2.ui.swt.Main "$@" [xxx@xxx ~]$ Version-Release number of selected component (if applicable): azureus-2.5.0.0-8.fc6 How reproducible: always Steps to Reproduce: 1. install sun jvm 2. make sure it is selected as aleternative 3. run azureus Actual results: azureus crashes right after opening its main window Expected results: no crash occurs Additional info: I have installed sun jvm using nosrc rpm method. which java && java -version returns the following: /usr/bin/java java version "1.5.0_09" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b01) Java HotSpot(TM) Client VM (build 1.5.0_09-b01, mixed mode, sharing)
I can't reproduce this, although my java is a little older. $ which java && java -version /usr/bin/java java version "1.5.0_06" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_06-b05) Java HotSpot(TM) Client VM (build 1.5.0_06-b05, mixed mode, sharing) I'm on an x86 box. Are you, by any chance, running on an x86-64 machine? If this is the case, it's possible that your 32-bit Sun JRE is trying to load 64-bit JNI libraries (SWT, etc). This is mentioned, along with a solution, in the FC6 release notes.
I am on x86 box. I can examine the bug deeper if you tell me output of which commands to post.
One more thing: vanilla azureus was working fine with the same jvm.
I have started with fresh ~/.azureus and now the program seems to work fine. It seems that fedora's “installed” azureus' config is incompatibe with vanilla “copied” one.
Created attachment 139862 [details] Azureus crash log
Created attachment 139865 [details] Azureus crash log
It has started to crash again, although I did not touch the config. Seems to be some kind of Mandelbug. Anyway, I'm attaching the crash log.
Created attachment 140432 [details] A crash log
I had meant to put a comment to that previous post. Anyways ... I have experienced exactly the same behaviour. I am also using the 1.5.0_09 VM. It appears that the crash only happens after the first run, ie not when it's running the setup wizard and creating the .azureus directory. I have also been able to run the version from sf.net without any troubles.
*** Bug 212933 has been marked as a duplicate of this bug. ***
azureus don't want to run : $ azureus DEBUG::Mon Dec 11 19:12:40 CET 2006::org.gudy.azureus2.ui.swt.mainwindow.Initializer::run::310: java.lang.NoClassDefFoundError: org/gnu/gtk/IconTheme at org.gudy.azureus2.ui.swt.ImageRepository.getThemedIcon(ImageRepository.java:73) at org.gudy.azureus2.ui.swt.ImageRepository.loadImages(ImageRepository.java:130) at org.gudy.azureus2.ui.swt.mainwindow.Initializer.run(Initializer.java:210) at org.gudy.azureus2.ui.swt.mainwindow.SWTThread$1.runSupport(SWTThread.java:115) at org.gudy.azureus2.core3.util.AERunnable.run(AERunnable.java:38) at java.lang.Thread.run(Thread.java:595) $ which java && java -version /usr/bin/java java version "1.5.0_09" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b03) Java HotSpot(TM) Client VM (build 1.5.0_09-b03, mixed mode, sharing)
running azureus on Linux Fedora 6 with JDK6 I receive: changeLocale: *Default Language* != English (United States). Searching without country.. changeLocale: Searching for language English in *any* country.. changeLocale: no message properties for Locale 'English (United States)' (en_US), using 'English (default)' Exception in thread "main" java.lang.NoClassDefFoundError: org/bouncycastle/jce/spec/ECParameterSpec at com.aelitis.azureus.core.security.impl.CryptoManagerImpl.<init>(CryptoManagerImpl.java:75) at com.aelitis.azureus.core.security.impl.CryptoManagerImpl.getSingleton(CryptoManagerImpl.java:60) at com.aelitis.azureus.core.security.CryptoManagerFactory.getSingleton(CryptoManagerFactory.java:33) at com.aelitis.azureus.core.impl.AzureusCoreImpl.<init>(AzureusCoreImpl.java:155) at com.aelitis.azureus.core.impl.AzureusCoreImpl.create(AzureusCoreImpl.java:92) at com.aelitis.azureus.core.AzureusCoreFactory.create(AzureusCoreFactory.java:46) at org.gudy.azureus2.ui.swt.Main.<init>(Main.java:143) at org.gudy.azureus2.ui.swt.Main.main(Main.java:162)
(In reply to comment #12) > running azureus on Linux Fedora 6 with JDK6 I opened bug #220131 about this.
This is the same as bug 216995 and figuring out what the actual problem is is blocked on bug 217004.
Has anybody tried this with with JDK 1.6 yet? I'd like to close this bug because it's not reproduceable with Free Software. On the other hand, I'd feel better about closing it if JDK 1.6 was an acceptable work-around (since we know that azureus performance on gcj 4.1.1 still isn't competitive).
it seems that jdk 1.6 is quite difficult to install and don't work with firefox. No ?
(In reply to comment #16) > it seems that jdk 1.6 is quite difficult to install and don't work with firefox. > No ? fitzsim is going to upgrade jpackage-utils this week so we can use the JDK6 compat package (maybe I'll submit that to Extras). This should make it easier to install JDK6. I don't know about the firefox problem - but you should be able to use a 1.5 JDK pluging for firefox while using JDK6 for azureus. We'll see...
Created attachment 144047 [details] Crash log with JDK6 This also crashes with JDK6. Here's my crash log.
It looks like gtk is trying to log a message through a callback in libgtk-java, and libgtk-java's handler is calling back into the VM in a way to cause it to die. The message is "gtk_widget_size_allocate(): attempt to allocate widget with width 250 and height -1". So one work-around may be to figure out why we're trying to create a negative-height widget and fix that, but we should really figure out why the message logging is failing. I'll poke at it a little more.
It is dying in the VM when we call... (*env)->ExceptionClear(env); Perhaps the JNI environment is corrupt. Still looking....
Actually, I was wrong... org_gnu_glib_GObject.c from libgtk-java contains.. gobject = (*env)->FindClass(env, "org/gnu/glib/GObject"); stackHandler = (*env)->GetStaticMethodID(env, gobject, "printStackTrace", "(Ljava/lang/String;)V"\ ); But FindClass is returning null, which causes the GetStaticMethodID call to fail within the VM. When I run azureus with -verbose:class I see that org.gnu.glib.GObject is being loaded, so it's not like it doesn't exist. Could it have something to do with how FindClass works within JNI code? See this.... http://java.sun.com/docs/books/jni/html/functions.html#52110 It says: "In Java 2 SDK release 1.2, FindClass locates the class loader associated with the current native method. If the native code belongs to the null loader, then it uses the bootstrap class loader to load the named class or interface. Otherwise, it invokes the ClassLoader.loadClass method in the corresponding class loader to load the named class or interface." I've lost much of what I once knew about class loaders. Is it possible that this JNI code (from libgtkjni-2.8.so) "belongs to the null loader"? I guess that would explain why it can't find GObject.
For it to be loaded by the null loader it would have to be on the boot class path. ("it" == the jar holding GObject.class) It is more likely, I think, that gobject is being loaded either by the system class loader (meaning the jar is on the ordinary classpath) or by some custom class loader in the application.
I've patched the gtk jni code as per Bug 220274, and now I get errors like the following.... Exception in thread "Universal Plug and Play (UPnP)::SSDP:queryLoop" java.lang.NoClassDefFoundError: org/gnu/glib/GObject at java.lang.Thread.sleep(Native Method) at com.aelitis.net.upnp.impl.ssdp.SSDPIGDImpl.queryLoop(SSDPIGDImpl.java:123) at com.aelitis.net.upnp.impl.ssdp.SSDPIGDImpl$1.runSupport(SSDPIGDImpl.java:86) at org.gudy.azureus2.core3.util.AERunnable.run(AERunnable.java:38) at org.gudy.azureus2.pluginsimpl.local.utils.UtilitiesImpl$2.runSupport(UtilitiesImpl.java:274) at org.gudy.azureus2.core3.util.AEThread.run(AEThread.java:69) I still have no idea why it can't load GObject.
Created attachment 144164 [details] error log
updating azureus to azureus.i386 2.5.0.0-11.fc6 and jpackage-utils to jpackage-utils.noarch 1.7.3-1jpp.1.fc6 leads to : $ azureus # # An unexpected error has been detected by HotSpot Virtual Machine: # # Internal Error (53484152454432554E54494D450E43505001A3), pid=5105, tid=3086460608 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_09-b03 mixed mode, sharing) # An error report file with more information is saved as hs_err_pid5105.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # /usr/bin/azureus: line 18: 5105 Abandon LD_LIBRARY_PATH=/usr/lib/eclipse:/usr/lib CLASSPATH=/usr/lib/eclipse/swt-gtk-3.2.jar:`build-classpath bcprov jakarta-commons-cli log4j gtk2.8 glib0.2`:/usr/share/azureus/Azureus2.jar java -Dgnu.gcj.runtime.VMClassLoader.library_control=never -Dazureus.install.path=$APPDIR org.gudy.azureus2.ui.swt.Main "$@" $ which java && java -version /usr/bin/java java version "1.5.0_09" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_09-b03) Java HotSpot(TM) Client VM (build 1.5.0_09-b03, mixed mode, sharing)
*** Bug 220678 has been marked as a duplicate of this bug. ***
(In reply to comment #19) > > So one work-around may be to figure out why we're trying to create a > negative-height widget and fix that, I don't know if this info is helpful, but here it goes. For me the problem started when I tried to download a torrent with a dead tracker. Azureus resorted to its distributed hash table, but it was firewalled in my machine. It then started to crash as described here. When I opened the required ports for the DHT to work, it stopped crashing. It worked flawlessly since then. I'm running: FC6, fully patched java-1.5.0-sun-1.5.0.09-1jpp azureus-2.5.0.0-11.fc6
*** Bug 222411 has been marked as a duplicate of this bug. ***
It works fine for me now : $ which java && java -version /usr/bin/java java version "1.6.0" Java(TM) SE Runtime Environment (build 1.6.0-b105) Java HotSpot(TM) Client VM (build 1.6.0-b105, mixed mode, sharing) azureus-2.5.0.0-11.fc6
Under f7 it now crashes immediately using the Java 1.6.0_01 JVM. jupiter:~$ java -version java version "1.6.0_01" Java(TM) SE Runtime Environment (build 1.6.0_01-b06) Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_01-b06, mixed mode) jupiter:~$ azureus # # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00002aaaaaab41bd, pid=6611, tid=1076017488 # # Java VM: Java HotSpot(TM) 64-Bit Server VM (1.6.0_01-b06 mixed mode) # Problematic frame: # C [ld-linux-x86-64.so.2+0x91bd] # # An error report file with more information is saved as hs_err_pid6611.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # /usr/bin/azureus: line 18: 6611 Aborted LD_LIBRARY_PATH=/usr/lib64/eclipse:/usr/lib64 CLASSPATH=/usr/lib64/eclipse/swt-gtk-3.2.jar:`build-classpath bcprov jakarta-commons-cli log4j gtk2.8 glib0.2`:/usr/share/azureus/Azureus2.jar java -Dgnu.gcj.runtime.VMClassLoader.library_control=never -Dazureus.install.path=$APPDIR org.gudy.azureus2.ui.swt.Main "$@"
Created attachment 156536 [details] azureus crash log azureus-2.5.0.4-2.fc7 with Sun JVM 1.6.0_01
Seems to work here: azureus-2.5.0.4-2.fc7.x86_64 java-1.6.0-sun-0:1.6.0.2-1jpp.x86_64
Indeed, azureus starts on my Fedora 8, too: azureus-2.5.0.4-3.fc8.i386 java-1.7.0-icedtea-1.7.0.0-0.19.b21.snapshot.fc8.i586 Closing the bug.
Created attachment 249411 [details] Azureus crash log Not here, apparently. What is even worse, it does not work well with gcj either: java-1.7.0-icedtea-1.7.0.0-0.19.b21.snapshot.fc8.x86_64 java-1.7.0-icedtea-plugin-1.7.0.0-0.19.b21.snapshot.fc8.x86_64 azureus-2.5.0.4-3.fc8.x86_64 [jsikorski@snowball ~]$ azureus DEBUG::Tue Nov 06 17:09:34 CET 2007::com.aelitis.azureus.core.impl.AzureusCoreImpl$8::runSupport::512: java.lang.NullPointerException at org.gudy.azureus2.ui.swt.updater2.SWTUpdateChecker.initialize(SWTUpdateChecker.java:67) at org.gudy.azureus2.ui.swt.mainwindow.Initializer$4.started(Initializer.java:258) at com.aelitis.azureus.core.impl.AzureusCoreImpl$8.runSupport(AzureusCoreImpl.java:508) at org.gudy.azureus2.core3.util.AEThread.run(AEThread.java:69) # # An unexpected error has been detected by Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x00002aaaaae104b6, pid=22528, tid=1074792784 # # Java VM: IcedTea 64-Bit Server VM (1.7.0-b21 mixed mode linux-amd64) # Problematic frame: # V [libjvm.so+0x33b4b6] # # An error report file with more information is saved as: # /home/jsikorski/hs_err_pid22528.log # # 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. #
same problem here .. was working fine in F7 in F8 it crashes at startup with the same messages already posted in this bug.
Upgraded to azureus 3.0.3.4 in rawhide (should be in tomorrow). Works with IcedTea and Sun's JDKs