Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.

Bug 205193

Summary: azureus uses 100% cpu for a few minutes after start
Product: [Fedora] Fedora Reporter: Mephisto <mephisto>
Component: azureusAssignee: Anthony Green <green>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: extras-qa, sangu.fedora
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-11-11 16:34:22 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
Error log of first crash with sun-java 5.0
none
Error log of second crash with sun-java 5.0 none

Description Mephisto 2006-09-05 08:32:09 EDT
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.
Comment 1 Mephisto 2006-09-05 08:32:09 EDT
Created attachment 135547 [details]
Error log of first crash with sun-java 5.0
Comment 2 Mephisto 2006-09-05 08:34:00 EDT
Created attachment 135548 [details]
Error log of second crash with sun-java 5.0
Comment 3 Anthony Green 2006-10-03 07:22:31 EDT
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.
Comment 4 Mephisto 2006-10-03 08:05:50 EDT
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.
Comment 5 Anthony Green 2006-10-03 08:15:49 EDT
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!
Comment 6 Mephisto 2006-10-03 09:57:32 EDT
I can't, i'm using a custom kernel that does not support oprofile. Any other way
to get this info you need?
Comment 7 Anthony Green 2006-10-28 11:01:40 EDT
(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?
Comment 8 Anthony Green 2007-11-11 16:34:22 EST
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.