Bug 205193 - azureus uses 100% cpu for a few minutes after start
azureus uses 100% cpu for a few minutes after start
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: azureus (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Anthony Green
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-05 08:32 EDT by Mephisto
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
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 (Terms of Use)
Error log of first crash with sun-java 5.0 (31.29 KB, text/plain)
2006-09-05 08:32 EDT, Mephisto
no flags Details
Error log of second crash with sun-java 5.0 (28.94 KB, text/plain)
2006-09-05 08:34 EDT, Mephisto
no flags Details

  None (edit)
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.

Note You need to log in before you can comment on or make changes to this bug.