amule 2.3.3 - gui freezes

T

tingo

trying to run amule 2.3.3 installed from a package here. The gui works when I start amule, but soon after (within a minute or two) it prints this message in the shell I started it from
Code: 
(amule:4687): GLib-CRITICAL **: 12:58:08.132: Source ID 721 was not found when attempting to remove it
and the the gui is frozen solid - not even window updates. I can start with an empty ~/.aMule directory, but as soon as I have a working configuration and have restarted amule, the gui freezes.
This on
Code: 
root@kg-quiet:~ # freebsd-version -ku
12.3-RELEASE-p5
12.3-RELEASE-p5
amule and everything else is installed from packages
Code: 
root@kg-quiet:~ # pkg -vv | grep url
    url             : "pkg+http://pkg.FreeBSD.org/FreeBSD:12:amd64/quarterly",
root@kg-quiet:~ # pkg info amule\*
amule-2.3.3_3
Additional info: amule slowly eats away at the memory until swap is exhausted and amule is killed. In top I can see that it climbs 5G, 10G, 15G, etc until it is killed because of out of swap.
this is a bit annoying, because the previous version of amule was working well...
 
Yes - amule-devel works. Thanks!
(I see that it uses wx28-gtk2 instead of wx30-gtk3 that amule 2.3.3 uses. Perhaps that is the reason)
 
I was thinking of details like:
- FreeBSD version?
- installed from package or ports? (if package, latest or quarterly repo?)
- what options (if installed from ports)?
 
I found that when I rename ~/.aMule the problem goes away until I give it some actual work to do, such as adding downloads or sharing files. It comes back after a short period of activity. I saw the same thing when I first updated I was able to use it for a while and do a search or two before the lock-up kicked-in. It doesn't suprize me if someone was able to launch amule without error.

I'm not sure the GLib error is relevant. It was reported here between 2013 and 2019 in Ubuntu in several applications, with the warning mostly not being associated with any other problems.

I'm using quarterly packages, has this already been fixed in the latest packages?
 
I switched to amule-devel, and it worked until the last quarterly update, but it's now dumping core with a segmentation fault.
 
FWIW, I'm still running this
Code: 
root@kg-quiet:~ # freebsd-version -ku
12.3-RELEASE-p5
12.3-RELEASE-p5
root@kg-quiet:~ # pkg -vv | grep url
    url             : "pkg+http://pkg.FreeBSD.org/FreeBSD:12:amd64/quarterly",
root@kg-quiet:~ # pkg info amule\*
amule-devel-11065_2
yes I know - I don't update that machine very often.
 
ok, the machine got updated
Code: 
root@kg-quiet:~ # freebsd-version -ku
12.4-RELEASE-p1
12.4-RELEASE-p2
all packages got updated too. Unfortunately, amule-devel has expired, so I'm back with amule (I see that it has recently been updated - thanks!)
Code: 
root@kg-quiet:~ # pkg info amule\*
amule-2.3.3_5
But it seems like the gui is still frozen solid.
 
and amule eats up memory and swap, until FreeBSD starts killing off processes.
Code: 
May 29 00:35:44 kg-quiet kernel: swap_pager_getswapspace(20): failed
May 29 00:35:47 kg-quiet kernel: pid 1170 (amule), jid 0, uid 1001, was killed: out of swap space
May 29 00:35:49 kg-quiet kernel: pid 1040 (Xorg), jid 0, uid 0, was killed: out of swap space
May 29 00:36:50 kg-quiet kernel: swap_pager_getswapspace(24): failed
 
If I try to run amuled instead amuled -e -c ~/.aMule/ itcrashes after a few minutes, with a core dump. gdb says
Code: 
tingo@kg-quiet:~ $ gdb /usr/local/bin/amuled --core=./amuled.core 
GNU gdb (GDB) 13.1 [GDB v13.1 for FreeBSD]
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-portbld-freebsd12.4".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/local/bin/amuled...
(No debugging symbols found in /usr/local/bin/amuled)
[New LWP 102514]
[New LWP 102043]
[New LWP 102513]

warning: Unexpected size of section `.reg-xstate/102514' in core file.
Core was generated by `amuled -e -c /home/tingo/.aMule/'.
Program terminated with signal SIGABRT, Aborted.
Sent by thr_kill() from pid 9851 and user 1001.

warning: Unexpected size of section `.reg-xstate/102514' in core file.
#0  0x000000080103ab8a in thr_kill () from /lib/libc.so.7
[Current thread is 1 (LWP 102514)]
(gdb) bt
#0  0x000000080103ab8a in thr_kill () from /lib/libc.so.7
#1  0x0000000801038f54 in raise () from /lib/libc.so.7
#2  0x00000000002b1c56 in ?? ()
#3  0x0000000800c7e95c in ?? () from /usr/local/lib/libwx_baseu-3.0.so.0
#4  0x0000000800c7cc8a in wxOnAssert(char const*, int, char const*, char const*, char const*) ()
   from /usr/local/lib/libwx_baseu-3.0.so.0
#5  0x0000000800d52bf0 in wxMappedFDIODispatcher::ModifyFD(int, wxFDIOHandler*, int) ()
   from /usr/local/lib/libwx_baseu-3.0.so.0
#6  0x0000000800d53720 in wxSelectDispatcher::ModifyFD(int, wxFDIOHandler*, int) ()
   from /usr/local/lib/libwx_baseu-3.0.so.0
#7  0x0000000800d57763 in ?? () from /usr/local/lib/libwx_baseu-3.0.so.0
#8  0x00000008004d161f in ?? () from /usr/local/lib/libwx_baseu_net-3.0.so.0
#9  0x00000008004ccf3e in wxSocketBase::Write(void const*, unsigned int) ()
   from /usr/local/lib/libwx_baseu_net-3.0.so.0
#10 0x00000000003ad2cf in ?? ()
#11 0x00000000002fab40 in ?? ()
#12 0x00000000002def69 in ?? ()
#13 0x000000000034543d in ?? ()
#14 0x0000000800d607dc in ?? () from /usr/local/lib/libwx_baseu-3.0.so.0
#15 0x000000080045ffd6 in ?? () from /lib/libthr.so.3
#16 0x0000000000000000 in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffdfdfd000
(gdb) quit
it doesn't matter if I connect amulecmd or not; amuled crashes either way.
 
Ktorrent cannot access the edonkey/kad network.

forums.freebsd.org

Solved - Amule won't run on FreeBSD-13.1-RELEASE because "segmentation fault" error.

Hello. Today I installed and tried to run net-p2p/amule and I saw that it didn't work. It caused the segmentation fault error. I've sent an email to the package maintainer and he replied to me like this: This existing bug report might be relevant...
forums.freebsd.org forums.freebsd.org

With one difference, I checked mldonkey on FreeBSD, it was quick and easy.
I don't understand resistance if you really want edonkey.
 
What does edonkey even have that KTorrent can't provide?

Check this out: https://en.wikipedia.org/wiki/Magnet_URI_scheme

For educational purposes (just figuring out how edonkey even works, and what it's limited by), playing with edonkey is a nice idea.

For going after specific files like FreeBSD iso's (or anything else, for that matter), KTorrent can't be beat.

If you want the kitchen sink, then net-p2p/vuze is your best bet (Yes, it can do the ed2k, too!) but it's a bulky thing that requires Java, and is actually quite the resource hog.
 
Don't focus on edonkey - nobody is using that. amule does Kademlia too, that's what's being used.
Also - it would be nice if this thread could stay on topic, instead of branching out into various "use X instead". If you want that create your own thread for it.
 
I'm sorry to offer an alternative but I really think amule is dying and mldonkey is an acceptable alternative.
 
CuatroTorres said:
I'm sorry to offer an alternative but I really think amule is dying and mldonkey is an acceptable alternative.
Click to expand...

Unless it's also as bad on Linux, it's fairer to say that FreeBSD is dying. FWIW I switched from mldonkey to amule years ago because at the time the former hardly ever worked. In the long-term, I still think amule is the better bet; it likely has a much larger user base and it's written in a mainstream language. It's a pain to have to switch back and forwards between file sharing clients, abandoning all the partial downloads. I'm also not keen to go back to having a daemon+GUI.
 
Installed amule from ports, first with default options - as expected amuled crashed within minutes. Next I change the BOOST option to "on" and reinstalled amule. More testing followed. amuled ran for five hours before I shut it down cleanly. I used amulecmd to interact with amuled. I am now testing amule, so far it has been running for around one hour. The gui works, and is as usable as before, even if parts of it look a bit different (the horizontal divider lines on the graphs). It doesn't look like it eats memory either.
 
Can you check that the overall download speed matches the real one? Downloads show a sustained speed while in the status bar it drops to 0 in a couple of minutes. Thanks in advance.

How does FreeBSD act accordingly? Should the binary include Boost dependencies in the next quarter?
 
CuatroTorres said:
Can you check that the overall download speed matches the real one? Downloads show a sustained speed while in the status bar it drops to 0 in a couple of minutes. Thanks in advance.
Click to expand...
I don't understand the question. How would you check it? FWIW, my statusbar shows a download speed that is different from zero as long as amule is downloading.
 
Ok. While the files show a constant download speed (yellow square in the example image), in the bottom bar (red) the speed is set to 0 in a couple of minutes, the file downloads truly stalls. It happens to me on Win/Linux/FreeBSD, I must close and open again to get the maximum speed again while keeping the turn of the seeders.

amule_example.jpg
 
You must log in or register to reply here.
Back
Top