rtorrent crashes on FreeBSD 14.1

Backtrace with debug compiled into libtorrent:
Code: 
(gdb) bt
#0  _sendto () at _sendto.S:4
#1  0x0000000826e55a4d in __thr_sendto (s=40, m=0x2c15f6b45ba0, l=10, f=0, 
    t=0x0, tl=0) at /xcarb3/usr/src/lib/libthr/thread/thr_syscalls.c:529
#2  0x000000082429e3e7 in torrent::SocketStream::write_stream (
    this=<optimized out>, buf=0x2c15f6b45ba0, length=<optimized out>)
    at ./socket_stream.h:94
#3  torrent::SocketStream::write_stream_throws (this=<optimized out>, 
    buf=0x2c15f6b45ba0, length=<optimized out>) at socket_stream.cc:80
#4  0x00000008242af30c in torrent::PeerConnectionMetadata::event_write (
    this=0x2c15f3120600) at peer_connection_metadata.cc:353
#5  0x000000082423ad3e in torrent::PollKQueue::perform (
    this=this@entry=0x2c15ef65b190) at poll_kqueue.cc:252
#6  0x000000082423aeb9 in torrent::PollKQueue::do_poll (this=0x2c15ef65b190, 
    timeout_usec=<optimized out>, flags=<optimized out>) at poll_kqueue.cc:285
#7  0x0000000824271342 in torrent::thread_base::event_loop (
    thread=0x2c15ef6c5080) at thread_base.cc:174
#8  0x00000000002808ed in ?? ()
#9  0x000000082ab5fbea in __libc_start1 (argc=26, argv=0x82066e5d8, 
    env=0x82066e6b0, cleanup=<optimized out>, mainX=0x27f650)
    at /xcarb3/usr/src/lib/libc/csu/libc_start1.c:157
#10 0x000000000027e6a0 in ?? ()

Too bad it doesn't have the file descriptor number as a function parameter. Would like to know what the pipe is connected to.

Code: 
(gdb) l
89      inline int
90      SocketStream::write_stream(const void* buf, uint32_t length) {
91        if (length == 0)
92          throw internal_error("Tried to write to buffer length 0.");
93
94        return ::send(m_fileDesc, buf, length, 0);
95      }
96
97      }
98
(gdb) p m_fileDesc,
A syntax error in expression, near `'.
(gdb) p m_fileDesc
value has been optimized out
 
Strangely enough my 15-current run is still going. Seems like 14.1 might actually cause the pipe error. If -current is an option for you and you need rtorrent that might be something to try.
 
This thread piqued my interest. I was not able to replicate it on 14.1 (releng/14.1-n267679-10e31f0946d8) with applied forementioned patch and versions:

Code: 
libtorrent-0.13.8
rtorrent-0.9.8

In paralel machine was downloading and seeding something small, leeching something slow and something fast (4GB download averaging at 80MBps). Client is running for a day or so.
 
_martin said:
This thread piqued my interest. I was not able to replicate it on 14.1 (releng/14.1-n267679-10e31f0946d8) with applied forementioned patch and versions:

Code: 
libtorrent-0.13.8
rtorrent-0.9.8

In paralel machine was downloading and seeding something small, leeching something slow and something fast (4GB download averaging at 80MBps). Client is running for a day or so.
Click to expand...
Idk if it makes a difference, but I have 12 terabytes of data controlled by rtorrent and crashes after a few minutes.
 
davorb said:
Idk if it makes a difference, but I have 12 terabytes of data controlled by rtorrent and crashes after a few minutes.
Click to expand...

Yeah, the SIGPIPE seems to happen on sitting there or very slow transfers. Fast download works fine.

Interestingly my FreeBSD-current run is still ongoing.
 
Reading this thread has me thinking that maybe OP would benefit from moving from rtorrent to some other torrent client... I use KTorrent, I compiled it from ports on several processors (primarily AMD 5000 series), and it works great, no crashes. ?
 
davorb said:
Idk if it makes a difference, but I have 12 terabytes of data controlled by rtorrent and crashes after a few minutes.
Click to expand...
That I'm unable to test.

I tried those 3 types of downloads though and was not able to trigger the bug. If you have something publicly shareable that is triggering the bug (and it's not 12TB) please let me know.
 
davorb said:
Idk if it makes a difference, but I have 12 terabytes of data controlled by rtorrent and crashes after a few minutes.
Click to expand...
? 12 TB??? All of my torrent-related data barely adds up to just over 2TB, but I guess that depends on what kind of data it is. My biggest torrent ever was just over 90GB, most are like 4-8 GB, but I'm happy with what I got. Yeah, when you have that much data controlled by torrents, the OS will start bursting at seams. ? ?
 
astyle said:
? 12 TB??? All of my torrent-related data barely adds up to just over 2TB, but I guess that depends on what kind of data it is. My biggest torrent ever was just over 90GB, most are like 4-8 GB, but I'm happy with what I got. Yeah, when you have that much data controlled by torrents, the OS will start bursting at seams. ? ?
Click to expand...

Should be a piece of cake with working application software.
 
I rebuilt all of my packages from ports, and not just rtorrent. And so far, it looks like it's stable. Will report back in a few days.
 
Unless the signal is handled elsewhere, the:

Code: 
return ::send(m_fileDesc, buf, length, 0);

Should probably be:

Code: 
return ::send(m_fileDesc, buf, length, MSG_NOSIGNAL);
 
kpedersen said:
Unless the signal is handled elsewhere, the:

Code: 
return ::send(m_fileDesc, buf, length, 0);

Should probably be:

Code: 
return ::send(m_fileDesc, buf, length, MSG_NOSIGNAL);
Click to expand...

I still wonder whether the signal is legitimate, aka does something die in there that shouldn't die on 14?
 
cracauer@ said:
I still wonder whether the signal is legitimate, aka does something die in there that shouldn't die on 14?
Click to expand...
Hmm, good point. The manpage says:

MSG_NOSIGNAL is used to request not to send the SIGPIPE signal if an attempt to send is made on a socket that is shut down for writing or no longer connected
Click to expand...

The logic is wrong if it is trying to send on a known shut down socket but I am not so sure what happens if it disconnects half-way through a send (if the connection is slow, this could happen (for blocking and non-blocking sockets)). Perhaps 14 is handling it differently. The concept of a "disconnect" is a little more involved to detect at the socket layer so I always skip the risk and pass that flag.
 
You must log in or register to reply here.
Back
Top