Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
This issue seen with Vuze 4.3.10 and gcc-java-4.3.3-i4 running on Slackware 13.0 32-bit.
Installed Vuze 4.3.10 from Vuze_4.3.1.0_linux.tar.bz2 downloaded from Sourceforge and tested OK as non-root user using ~/.azureus configuration from previous 4.2.0.8. OK. Did not use for a week. Opened the Slackware 13.0 32-bit DVD torrent using Firefox 3.5.3. Saw Vuze message advising torrent had been added but Vuze exited.
Started Vuze as same non-root user in a terminal using /opt/vuze/vuze &. Saw
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xa2c658f1, pid=8653, tid=2810555280
#
# JRE version: 6.0_16-b01
# Java VM: Java HotSpot(TM) Server VM (14.2-b01 mixed mode linux-x86 )
# Problematic frame:
# C [libxul.so+0xa008f1]
Presumably I'd have to uninstall gcc-java-4.3.3-i4 before installing the latest jre-6u*.
No there is no need to do so. They are 2 different things. You can install jre (jdk is an overkill if you don't need it) along with gcc-java, using your package manager.
Thanks (that was quick!) for correcting my ignorance, bathory
Code:
c@CW8:~$ /usr/lib/java/bin/java -version
java version "1.6.0_16"
Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
Java HotSpot(TM) Server VM (build 14.2-b01, mixed mode)
c@CW8:~$ ls /var/log/packages/*jre*
/var/log/packages/jre-6u16-i586-1
Could you try to delete the files /tmp/libswt*.so, or the directory /tmp/swtlib-32 (whatever exists for your setup) and restart azureus. These are created every time azureus starts if they don't exist.
Could you try to delete the files /tmp/libswt*.so, or the directory /tmp/swtlib-32 (whatever exists for your setup) and restart azureus. These are created every time azureus starts if they don't exist.
Thanks for that information about re-initialising azureus. I would try as you ask but have just now got 4.1.0.4 downloading the latest Knoppix DVD. This takes first priority, hopefully as a solution tfor resizing an ext4 root file system (this LQ thread)
Azureus' /tmp files may explain why 4.1.0.4 showed the 4.3.1.4 ChangeLog and displays 4.3.1.4 in Help->About ... ? (the /opt/vuze/ChangLog.txt is correct and other files in that directory have credible modification times for 4.1.0.4).
@bathory: in preparation for testing as you suggested are there any of these that I should not delete before testing a different version of azureus?
Code:
root@CW8:~# ls -l /tmp/*
-rwxr-xr-x 1 c users 23060 Feb 20 10:10 /tmp/libswt-atk-gtk-3448.so
-rwxr-xr-x 1 c users 40736 Feb 20 10:10 /tmp/libswt-cairo-gtk-3448.so
-rwxr-xr-x 1 c users 11360 Feb 20 10:10 /tmp/libswt-gtk-3448.so
-rwxr-xr-x 1 c users 352084 Feb 20 10:10 /tmp/libswt-pi-gtk-3448.so
-rwxr-xr-x 1 c users 27528 Feb 20 10:10 /tmp/libswt-xpcominit-gtk-3448.so
-rwxr-xr-x 1 c users 73432 Feb 20 10:10 /tmp/libswt-xulrunner-gtk-3448.so
/tmp/hsperfdata_c:
total 32
-rw------- 1 c users 32768 Feb 20 10:20 4601
[snip]
@bathory: in preparation for testing as you suggested are there any of these that I should not delete before testing a different version of azureus?
Yup, if you're afraid to break anything, you can move them to a different place. They are the same with those I see on my box when I run vuze/azureus, apart from libswt-xulrunner-gtk-3448.so (maybe that's the culprit as vuze crashes with a libxul error).
The hsperfdata_c directory is used by vuze to create a file with its PID. The file is deleted when you stop vuze.
Quote:
Meanwhile the Knoppix torrent is ~50% downloaded ...
Yup, if you're afraid to break anything, you can move them to a different place. They are the same with those I see on my box when I run vuze/azureus, apart from libswt-xulrunner-gtk-3448.so (maybe that's the culprit as vuze crashes with a libxul error).
The hsperfdata_c directory is used by vuze to create a file with its PID. The file is deleted when you stop vuze.
2 days for 50%. What is your download speed?
They all disappear when Vuze is stopped; perhaps not if it crashes (EDIT: so I'm not worried about breakage).
1 GB per day download; you are right to ask! The answer is not simple ...
The "broadband" package gives us 512 kbps "wherever technically feasible" and we do get 64 kBps at best. But I share the connection with others so must throttle back the download speed when they are using it. That would give ~10 hours of full speed equivalent per day except we are having trouble with our new ADSL modem/router (Cisco-Linksys WAG54G2 -- not a good choice in retrospect). It dropped out of service while I was torrenting at 45 kBps and would not work again, even after a 40 minute cooling period. Was OK in the morning. That lost an entire night and since then I've been edging the download speed up from 32 kBps, not wanting to loose another night.
After some debate (it's not my decision) it has been agreed to take the modem back under warranty.
They all disappear when Vuze is stopped; perhaps not if it crashes (EDIT: so I'm not worried about breakage).
I've tested on 3 computers (2 running Slackware and 1 running Suse) and these libraries stay even when vuze stops normally.
The only difference is, that the first 2 (versions 4.3.1.4 and 4.2.0.4) put the temp files in /tmp/swtlib-32 directory, while the 3rd (version 3.0.42) puts them in /tmp.
I've tested on 3 computers (2 running Slackware and 1 running Suse) and these libraries stay even when vuze stops normally.
The only difference is, that the first 2 (versions 4.3.1.4 and 4.2.0.4) put the temp files in /tmp/swtlib-32 directory, while the 3rd (version 3.0.42) puts them in /tmp.
Thanks for that information
Re-testing 4.3.1.4 with no Vuze files in /tmp and no ~/.azureus produced the same result.
Following a suggestion in the Vuze forum thread, Vuze 4.3.1.4's swt.jar (version 3.631) was replaced with swt.jar version 3.550. Testing (again with no Vuze files in /tmp and no ~/.azureus) produced the same result except with less debug output.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.