Red Hat Bugzilla – Bug 205193
azureus uses 100% cpu for a few minutes after start
Last modified: 2007-11-30 17:11:42 EST
Description of problem: Azureus uses 100% cpu for a few minutes after start when used with gcj's jre as included with FC devel. Version-Release number of selected component (if applicable): azureus-2.5.0.0-1.2.fc6 libgcj-4.1.1-20 How reproducible: always Steps to Reproduce: 1. Install azureusa and set gcj's jre as default java runtime (this is also the default setting). 2. Start azureus. 3. Monitor CPU usage. Actual results: Azureus takes up 100% cpu for a few minutes. Expected results: Azureus should go back to normal usage after completing startup. Additional info: This also happens with the official azureus as downloaded from the website, running on gcj. This does not happen with sun's official 5.0 jre. The official azureus build with sun's 5.0 works fine. The FC build with sun's jre needs a slight modification to the startup script to function (add gcj-endorsed/bcprov-1.33.jar to the classpath), and crashes a few seconds after showing the main screen, with one of the following errors: # An unexpected error has been detected by HotSpot Virtual Machine: # # SIGSEGV (0xb) at pc=0xb0931ed2, pid=12119, tid=3085227712 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing) # Problematic frame: # C [libgtkjni-2.8.so+0x7aed2] # # An error report file with more information is saved as hs_err_pid12119.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp # An unexpected error has been detected by HotSpot Virtual Machine: # # Internal Error (53484152454432554E54494D450E43505001A3), pid=12003, tid=3084510912 # # Java VM: Java HotSpot(TM) Client VM (1.5.0_06-b05 mixed mode, sharing) # An error report file with more information is saved as hs_err_pid12003.log # # If you would like to submit a bug report, please visit: # http://java.sun.com/webapps/bugreport/crash.jsp I will attach the error logs from both errors, as i think this may indicate a bug in one or more libraries.
Created attachment 135547 [details] Error log of first crash with sun-java 5.0
Created attachment 135548 [details] Error log of second crash with sun-java 5.0
What does your /usr/lib/security/classpath.security file look like? libgcj may be trying to initialize a random number generator using a rediculously CPU intensive routine. If your classpath.security file doesn't contain this... securerandom.source=file:///dev/urandom ...please add it and report back. Thanks.
i got this: # The VM-wide default callback handler class name. MUST be a subclass of # javax.security.auth.callback.CallbackHandler auth.login.defaultCallbackHandler=gnu.javax.security.auth.callback.DefaultCallbackHandler # If this file isn't found we fall back to generating entropy through # "battling threads". securerandom.source=file:///dev/urandom security.provider.1=gnu.java.security.provider.Gnu security.provider.2=gnu.javax.crypto.jce.GnuCrypto security.provider.3=gnu.javax.crypto.jce.GnuSasl security.provider.4=gnu.javax.net.ssl.provider.Jessie security.provider.5=gnu.javax.security.auth.callback.GnuCallbacks security.provider.6=org.bouncycastle.jce.provider.BouncyCastleProvider security.provider.7=gnu.crypto.jce.GnuCrypto Not sure if i have to remove something from this, but i already had /dev/urandom as securerandom.source.
Hmm.. ok. Please install azureus and libgcj debug info, as well as oprofile. Then... $ opcontrol --init $ oprof_start (and check "No kernel image") then start profiling, run azureus, and when the CPU usage returns to normal, stop profiling. Then run "opreport -l" and send me the results. Thanks!
I can't, i'm using a custom kernel that does not support oprofile. Any other way to get this info you need?
(In reply to comment #6) > I can't, i'm using a custom kernel that does not support oprofile. Any other way > to get this info you need? I can't think of any way. Is there no way for you to boot the standard kernel just for this test?
I'm closing this with WONTFIX as now we have IcedTea and the problems reported here are related to gcj and Sun's proprietary java. Please run azureus with IcedTea.