Ticket #496 (closed defect: fixed)

Opened 5 years ago

Last modified 5 years ago

Changing system time may crash rtorrent

Reported by: spam.nospam.spam@gmail.com Owned by: rakshasa
Priority: low Component: rtorrent
Version: HEAD Severity: critical
Keywords: segfault clock time ntp Cc:

Description

When I updated the system time (which was running ~360s ahead) of the computer rtorrent was running on, rtorrent crashed with this message:

Caught Segmentation fault, dumping stack:
0 rtorrent [0x8057601]
1 rtorrent [0x806856c]
2 /lib/tls/i686/cmov/libc.so.6 [0x9c670a48]
3 /usr/local/lib/libtorrent.so.9(_ZN7torrent11FileManager10close_fileEPNS_8FileMetaE+0x1a) [0x9cb82e16]
4 /usr/local/lib/libtorrent.so.9(_ZN7torrent11FileManager18close_least_activeEv+0x7e) [0x9cb82f8c]
5 /usr/local/lib/libtorrent.so.9(_ZN7torrent11FileManager12prepare_fileEPNS_8FileMetaEii+0xdc) [0x9cb8346a]
6 /usr/local/lib/libtorrent.so.9(_ZN7torrent9EntryList12create_chunkExji+0x254) [0x9cb80772]
7 /usr/local/lib/libtorrent.so.9(_ZN7torrent7Content12create_chunkEjb+0x66) [0x9cb7d04e]
8 /usr/local/lib/libtorrent.so.9(_ZN7torrent9ChunkList3getEjb+0x1df) [0x9cb79d1d]
9 /usr/local/lib/libtorrent.so.9(_ZN7torrent18PeerConnectionBase13load_up_chunkEv+0x60) [0x9cba8e30]
10 /usr/local/lib/libtorrent.so.9(_ZN7torrent19PeerConnectionLeech11event_writeEv+0x15d) [0x9cbabdf7]
11 /usr/local/lib/libtorrent.so.9(_ZN7torrent9PollEPoll7performEv+0xb4) [0x9cb6aefc]
12 rtorrent [0x80a2f9e]
13 rtorrent [0x8059311]
14 /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xd2) [0x9c65cea2]
15 rtorrent(_ZN7torrent18set_max_open_filesEj+0x85) [0x80518a1]

How it happened: I was watching the session directory (remote computer running Ubuntu 6.06) because I was wondering if session files were periodically updated. (turns out they are) I noticed that their timestamp was a few minutes ahead of my own clock. I checked the system time, found that the system time was way off and updated it with ntpdate. A second later rtorrent segfaulted on me, so I suppose it didn't really appreciate me tampering with the system time and some internal calculations to find which file handle to free went wrong.

Change History

Changed 5 years ago by rakshasa

  • status changed from new to closed
  • resolution set to fixed

Ok, looks like it didn't like having cachedTime before the 'last touched' timers of the files.

Note: See TracTickets for help on using tickets.