rtorrent randomly ignores half of the trackers in the list of trackers.

[Antorell]

rtorrent randomly ignores half of the trackers when starting a new torrent with multiple mixed UDP/HTTP trackers. Sometimes rtorrent scrapes all the trackers, most of the time it doesn't. edit: I mean it scrapes the trackers it usually ignores that are alive that have seeds/peers for the same torrent.

rtorrent and libtorrent, up to date to the latest commit from the github repos, no patches were applied.

Edit2: UDP trackers are enabled. See below

Above is Qbitorrent, bellow is rtorrent

Debug log, torrent from subsplease. rtorrent.60630.log

On the other hand, it doesn't have any issue with torrents with just a few trackers.

[stickz]

@Antorell My solution was to reduce the number of maximum http and udp sockets to 256. Does this work for you? In .rtorrent.rc add the following commands.

network.http.max_open.set = 256
network.max_open_sockets.set = 256

[Antorell]

I fixed it another way. I stopped using listen to all (including IPV6 address), bound rtorrent to an IPV4 address and I patched rtorrent to force it to listen to a IPV4 TCP socket instead of the default IPV6 TCP socket with IPV4 mapped to IPV6 address on my dual stack system. UDP trackers don't seems to get skipped as often or at all. But that's not going to be a long fix I think, rtorrent segfaults when running on Ubuntu 23.10 with torrents using at least 1 UDP tracker on my test box.

This is what I get when I load a torrent that has at least one UDP trackers with vanilla rtorrent install, main branch or feature/tracker-pv6, no patch applied, whatsoever.

[ Removed -> Gcc bug ]

[stickz]

Can you obtain a proper stack trace using gdb? This one is not detailed enough to show the problem. It's relatively easy. apt install gdb then gdb rtorrent then type run in gdb console. After crash, type bt in gdb console.

If you want a long term fix, I just patched this problem with UDP trackers on swizzin with UDNS. It ignores IPV6 without causing a segfault to happen. Ubuntu 22.04LTS is known to be the most stable. https://github.com/swizzin/swizzin

It seems like you're constantly trying to reinvent the wheel with fixes. The swizzin project has 6 rtorrent patches and it's about to go up to 9 patches. With the addition of xml-rpc and data corruption fixes. https://github.com/swizzin/swizzin/pull/1084 I'm two steps ahead of what you're doing with patches. They're being distributed to vendors and the regular users like yourself.

[Antorell]

Can you obtain a proper stack trace using gdb? This one is not detailed enough to show the problem. It's relatively easy. apt install gdb then gdb rtorrent then type run in gdb console. After crash, type bt in gdb console.

I won't be able to do it, I just finished reinstalling my test box back to 23.04.

I didn't try to reinvent the wheel to fix the rtorrent skipping UDP trackers. It was just a side effect of patching rtorrent to force it to listen to an IPV4 TCP socket. My seedbox has /etc/gai.conf set to prefer IPV4 and network.bind_address.set bound to an IPV4 address, and I got fed up of seeing IPV6 peers poking a non-existant rtorrent port showing up in the IPV6 firewall logs of my seedbox. rtorrent still using TCP6 socket with a mapped IPV4 to IPV6 address when network.bind_address.set is set to an IPV4 is beyond me.

[stickz]

Can you obtain a proper stack trace using gdb? This one is not detailed enough to show the problem. It's relatively easy. apt install gdb then gdb rtorrent then type run in gdb console. After crash, type bt in gdb console.

I won't be able to do it, I just finished reinstalling my test box back to 23.04.

You can be up and running in 5 minutes on Ubuntu 22.04 LTS with swizzin. If you don't want IPV6, that can be disabled through the operating system. The best way to do it is through grub. Just make sure to check netplan to ensure IPV4 is bound first.

nano /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash ipv6.disable=1"
GRUB_CMDLINE_LINUX="ipv6.disable=1"
sudo update-grub
sudo reboot

If you disable IPV6 globally, rtorrent will have no choice to stick to IPV4. This method is fool-proof without any problems.

[Antorell]

Yes, thanks but I use IPV6 somewhere else, I just didn't want IPV6 for rtorrent anymore. Otherwise I would just have flipped the global switch in grub you mentioned instead of wasting an hour looking around in libtorrent's src/net.

[Antorell]

@stickz The segault is not related to Ubuntu 23.10, it's compiling with GCC 13 that causes rtorrent/libtorrent to crash/segfault when starting a torrent with an ~UDP~ tracker. edit: nvm UDP, compiled on ubuntu 23.04 with gcc-13 rtorrent crashes even with a single HTTP tracker.

Here the gdb log

[ removed -> Gcc bug ]

[stickz]

The compile log would be helpful, in-case someone wants to patch rtorrent to work properly with GCC 13. There is ABI breakage here, that should be shown in the compile log with a warning.

This is again an example of trying to re-invent the wheel. I have a perfectly stable rtorrent configuration compiled with GCC 12.3. It's actually faster with PGO support. It's much easier to use an installation script, than to sink hours on this task.

[Antorell]

I put the logs here. Maybe rakshasa will fix the problem when it'll be an issue and he won't be too busy.

[removed gcc bug]

I don't daily use the ubuntu test box that was running Ubuntu 23.10, I just happened to have upgraded/installed it on a test machine at home for reasons unrelated to rtorrent when I tried to run rtorrent on it. I just mentioned it yesterday because I thought it was worth mentioning. I don't use GCC-13 as default compiler either. Today I tried to compile with GCC-13 while running 23.04 because it crossed my mind this afternoon and I posted the gdb logs as it was the culprit of the segfaults.

gl.

[kannibalox]

Are you sure you've cleared out all the custom patches? I've been doing a lot of recent testing on GCC 13.2.1 (Arch), and Ubuntu 23.04 even has a package for 0.9.8. I also spun up a 23.04 docker image to try compiling master from scratch, and was unable to reproduce.

[Antorell]

Yes. I'm not stupid, I wouldn't have mentioned it if it was happening when I compiled a patched source.

This (the dbg) is a git pull from the master/main branch on a vanilla Ubuntu 23.04 reinstalled the day before AND compiled with GCC 13. I use Ubuntu 23.04 with rtorrent compiled with GCC-12 and it works perfectly fine.

Yesterday the segfault happened on a fresh install of 23.10 (installed a week before that hadn't been touched or booted, even, since).

edit: rtorrent 9.8 package on ubuntu 23.04 is compiled with GCC 12. The problem is not ubuntu, the problem shows up when compiling rtorrent on ubuntu (23.04 or 23.10) with GCC-13.

edit2 (tl;dr) If I tried to compile rtorrent on 23.04 with GCC-13 it's because it struck me that Ubuntu 23.10 defaults to GCC-13 now and I didn't try to compile rtorrent with gcc-12 on 23.10. So instead of wasting time reinstalling 23.10, I installed GCC-13 on 23.04 and tried that (the dbg log).

Edit3: It's compiling rtorrent/libtorrent with its --enable-arch= flag is what causes the segfaults.

[stickz]

Are you using the master branch or the release versions? There's a possibly the master branch may work properly with GCC 13.

The operating system is not responsible for this issue. It's the version of GCC being distributed with it causing the problem.

[Antorell]

Yes, I already mentioned I use rtorrent/libtorrent using a vanilla (no patch) git pull of Main/Master branch.

rtorrent/libtorrent doesn't segfault if I remove the --enable-arch=native from the /configure before compiling. I only have AMD machines at home, so I can't really check if it's specific to AMD. I have an intel MB+CPU but it's somewhere in a box god knows where. One of the server I use as seedbox is running Ubuntu 23.04 on an old Xeon CPU, I'll install GCC-13 on it to try again before I relinquish the server in a couple of days.

[Antorell]

rtorrent/libtorrent compile and run just fine on that old Intel Xeon CPU --with-arch=native set at compile time. It's an issue with Gcc Zen2 CPU optimizations.

In AMD zen 2 gcc -march=native -Q --help=target log -mmove-max= changed from 128 to 256. gcc_13.log gcc_12.log