Description of problem: Got his bz: (closed wontfix) https://bugzilla.redhat.com/show_bug.cgi?id=560232 This comment has a workaround\suggestion https://bugzilla.redhat.com/show_bug.cgi?id=560232#c48 I left a comment: https://bugzilla.redhat.com/show_bug.cgi?id=560232#c50 Asked come here for how to use it in azureus. azureus 4.8.1.2.1 (fedora packaged)
My apology, I really should get better at looking after Bugzillas )-: So first off, is this still a problem? To answer your question for implementing Deepak's workaround, add "-Dsun.zip.disableMemoryMapping" towards the end of the long last line of /usr/bin/azureus. So for azureus-5.0.0.0-1.fc19, the line would look like JAVA_HOME=/usr/lib/jvm/java-openjdk LD_LIBRARY_PATH=$LIBDIR/eclipse/plugins/:$LIBDIR/eclipse/:$LIBDIR CLASSPATH=$SWT:`build-classpath bcprov apache-commons-cli log4j`:/usr/share/azureus/Azureus2.jar java -Dazureus.install.path=$APPDIR -Dazureus.script.version=$SCRIPT_VERSION -Dazureus.script=$0 -Dorg.eclipse.swt.browser.UseWebKitGTK=true -Dsun.zip.disableMemoryMapping org.gudy.azureus2.ui.swt.Main "$@" But next question is, why are you receiving jar:s/zips that are changing, it sounds kind of weird... Could you please send me the full crash report from when this problem is happening?
(In reply to David Juran from comment #1) > My apology, I really should get better at looking after Bugzillas )-: > > So first off, is this still a problem? Honestly don't know if still a problem, > > To answer your question for implementing Deepak's workaround, add > "-Dsun.zip.disableMemoryMapping" towards the end of the long last line of > /usr/bin/azureus. So for azureus-5.0.0.0-1.fc19, the line would look like > > JAVA_HOME=/usr/lib/jvm/java-openjdk > LD_LIBRARY_PATH=$LIBDIR/eclipse/plugins/:$LIBDIR/eclipse/:$LIBDIR > CLASSPATH=$SWT:`build-classpath bcprov apache-commons-cli > log4j`:/usr/share/azureus/Azureus2.jar java -Dazureus.install.path=$APPDIR > -Dazureus.script.version=$SCRIPT_VERSION -Dazureus.script=$0 > -Dorg.eclipse.swt.browser.UseWebKitGTK=true -Dsun.zip.disableMemoryMapping > org.gudy.azureus2.ui.swt.Main "$@" > ok, will do that (script v2) > But next question is, why are you receiving jar:s/zips that are changing, it > sounds kind of weird... Could you please send me the full crash report from > when this problem is happening? The only time, that would happen (I guess ) is if I forget to disable check for updates, in the options, and it goes through the motions , but don't know enough about it (I got to primitives, that was all).
This may have fixed something as running solid overnight (10:30am -6:00am) or maybe the new swt.jar from @eclipse.org bz: #980260.
Did you mean that -Dsun.zip.disableMemoryMapping helped? Yes, according to Deepak Bhole, it's supposed to help, at the cost of performance, so I'm a bit hesitant to put it into the script for everybody. What I'm a bit curious about is why the (update?) jar which is being downloaded changes in mid-transfer. Or why I'm not seeing this issue myself... So if you have the possibility and would like to further debug this issue, could you try removing the -Dsun.zip.disableMemoryMapping from the startup script and then, when azureus crashes, submit the full crash log. If you enable abrt, it will make it easier for you to collect the core.
(In reply to David Juran from comment #4) > Did you mean that -Dsun.zip.disableMemoryMapping helped? > Yes, according to Deepak Bhole, it's supposed to help, at the cost of > performance, so I'm a bit hesitant to put it into the script for everybody. either that or the updated swt.jar, which was listed as part of the problem with the other apps on Deepak Bhole comments > > What I'm a bit curious about is why the (update?) jar which is being > downloaded changes in mid-transfer. Or why I'm not seeing this issue > myself... It could be that if azureus\openjdk crash out, I would the test upstream version, to see if it breaks something, it may overwrite "check update" bits in ~/.azureus > > So if you have the possibility and would like to further debug this issue, > could you try removing the -Dsun.zip.disableMemoryMapping from the startup > script and then, when azureus crashes, submit the full crash log. If you > enable abrt, it will make it easier for you to collect the core. Will give it a shot, now there is a newer OpenJdk* and eclipse-swt (sept 30) in F19-updates-testing, should I test those as part, or leave it as current.
lmk if I didn't get enough: ftp://ftp.frankly3d.eu/azureus.bz2
Is that a crash dump in #6? The ftp site requires a login...
(In reply to David Juran from comment #7) > Is that a crash dump in #6? The ftp site requires a login... Apologies, meant to give you the http://frankly3d.eu/fedora/azureus.bz2
More testing, maybe it's openjdk to blame for all things azureus\vuze? Downloaded upstream vuze (iirc 4.9.0.0) updated to 5.1.0.0 using inbuilt function. Separated .azureus from fedora ~/.azureus using: -Dazureus.config.path="${PROGRAM_DIR}"/.azureus \ # where appropriate (I cheated by copying original backup over, to avoid re-entering torrents) rm ~/.azureus to prove new path works. openjkd still doing it's drunken dance, numer of times over 30m vuze still open and running Will attach sceen cap of abrt@java
Created attachment 809813 [details] openjdk >> abrt screencap (30 min period)
More testing stated from terminal : /usr/bin/azureus https://bugzilla.redhat.com/show_bug.cgi?id=1016085#c21 + 22 hs*.log and massive core file
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
(In reply to David Juran from comment #4) > Did you mean that -Dsun.zip.disableMemoryMapping helped? I tried -Dsun.zip.disableMemoryMapping and seems doesn't help , seems more to me this is a dup of bug #980260 , which is SWT fault.
*** This bug has been marked as a duplicate of bug 980260 ***