Opened 6 years ago

Closed 3 years ago

Last modified 3 years ago

#4147 closed Bug (fixed)

Bad file descriptor

Reported by: fsarg3 Owned by:
Priority: Normal Milestone: 2.82
Component: Transmission Version: 2.22
Severity: Normal Keywords:
Cc: lolc.polc@…, ivailo@…

Description

I see that 2.30 is being prepared, so I must report some problems that I think are new to 2.22. It is possible that some are specific to my configuration, but I have seen some similar comments, so I will summarise some strange, but rare issues I have seen lately.

I have seen this issue on a small number of torrents, certainly less than 5%. https://forum.transmissionbt.com/viewtopic.php?f=4&t=11267 I run transmission-daemon on Ubuntu 10.04 though. The current torrent with this issue does not have extremely long path, it stops every few minutes with 'Bad file descriptor' for some random file, but can simply be restarted, with no issue evident, maybe a piece is lost. occasionally, this error follows, in the log: Error while flushing completed pieces from cache (session.c:532)

The second issue seems similar enough to possibly be related, so I include it here too. Rarely, a torrent is reporting a piece failed verification, but when I check it, nothing is missing.

Also, a small amount of seeded data has vanished. I mention this here, because it does not seem to be an underlying problem, as only specific torrents lost data, but those lost multiple chunks in every case. I do not think the files were modified by a different process, because the bad chunks are completely zeroed out in the cases I checked. I only found the torrents missing data when I verified all after seeing a few 'failed verification' errors. The problem torrents had not reported an error though.

Checking the log of this client, I notice yet another error I do not recall seeing before. A specific older torrent that had been seeding for many months was filling the log with tr_fdFileCheckout failed for [one particular small file]: Invalid argument (inout.c:127) I re-verified with no issue, and as soon as this completed, a peer with 99% connected, no data transferred however, and the peer disconnected.

Finally, as some of these issues result in extra download, I note one more issue that seems to have manifested in recent versions, but definitely prior to 2.22: If 'too many' simultaneous downloads are in process, transmission is reporting considerable extra 'Downloaded', with no explanation. Double the torrent size is not at all uncommon when I have observed this condition. If I also set some to 'low priority', or otherwise further starve them for bandwidth, it is not at all unlikely to see 10x downloaded after 24 hours. If this condition is not triggered the downloaded amount is generally extremely close to the actual size.

Change History (27)

comment:1 Changed 5 years ago by eris23

I'm running transmission-gtk currently Transmission 2.22 (12099) on Ubuntu 10.10 (Maverick) with various packages from ppas installed. I get the "bad file descriptor" described, and can restart the files without noticeable problems. Other completed files occasionally show a missing block, but can be restarted, and the block re-downloaded without noticeable problems. On particular other completed torrents I get the tr_fdFileCheckout followed by a "Couldn't truncate" visible in the message log, but those files never stop downloading.

comment:2 Changed 5 years ago by pocm

I'm getting this exact same error - glad it's not just me. It seems to be filesystem-independent, since I'm using JFS and the OP is using ext. And seems to be only affecting incomplete/downloading torrents. I've also noticed the reverting-to-99% problem but had no reason to conclude that was the same bug. Either way, a fix would be greatly appreciated.

comment:3 Changed 5 years ago by pocm

  • Cc lolc.polc@… added

comment:4 Changed 5 years ago by Grug

+1

I hate to do a "me too" without adding any other info, but I'm really not sure how to debug these issues.

I'm getting both the torrents pausing due to "Bad file descriptor" (manually restarted without issue), and about 50% of my completed torrents reverting back to 99% with a "Please verify Local Data: Piece #?? is corrupt" error (reverifying causes it to "revert" back to 100%).

I was wondering if this might be due to file system limits (open files or something) because I've got 197 torrents at the moment, but this still occurs with half of them paused.

comment:5 Changed 5 years ago by eris23

I still have the problem in Transmission 2.33, installed from a ppa, running in Ubuntu Natty amd64. I suspect it's a problem with the libevent library (2.0.10), so I'm installing the version from Oneiric (2.0.12).

comment:6 Changed 5 years ago by livings124

Can people report back on this with 2.33 (or eris23 with the updated libevent)?

comment:7 Changed 5 years ago by livings124

  • Resolution set to fixed
  • Status changed from new to closed

I believe this is not longer an issue in current release. Please reopen if it is.

comment:8 Changed 5 years ago by eris23

Running Transmission 2.42 (13013) from ppa on Ubuntu 11.10 (Oneiric Ocelot) amd64. Problem continues. Also had the same problem on Tranmission 2.33 from main repository.

comment:9 Changed 5 years ago by soloithz

Running Transmission 2.42 (13013) on OS X 10.7.2. Tried the latest nightly build, to no avail. I get this error on pretty much every torrent I download. I also am having the issue of the "Please verify Local Data: Piece #?? is corrupt" error on many of my torrents.

comment:10 Changed 5 years ago by soloithz

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:11 Changed 5 years ago by panaut0lordv

Hello, file descriptor happens on Ubuntu 11.10 which is is shipped with Transmission 2.33 too, but actually it was 2 or 3 times per year, something that you can get over but should be fixed anyway. Also I think https://trac.transmissionbt.com/ticket/1242 is quite related to issue of the "Please verify Local Data: Piece #?? is corrupt" error of soloithz and I'm experiencing this problem like on a half of my torrents. Today I'm going to check with Transmission version that ships with Ubuntu Precise.

comment:12 Changed 4 years ago by livings124

Is this still happening with 2.51? I haven't seen this reported in a while.

comment:13 Changed 4 years ago by livings124

  • Resolution set to worksforme
  • Status changed from reopened to closed

Please reopen if this is still an issue with current releases.

comment:14 Changed 4 years ago by eris23

Still occurs with Transmission 2.51 (13280) in Ubuntu Precise amd64 (but maybe not as often).

comment:15 Changed 4 years ago by nikel

  • Resolution worksforme deleted
  • Status changed from closed to reopened
  • Version changed from 2.22 to 2.51

Bug is still there. Here is some logs:

2012-04-29T00:24:16.662502+02:00 localhost transmission-daemon[2833]: <Some Torrent> write failed for "<Some Torrent>/<Some Torrent file>": Bad file descriptor (inout.c:132)
2012-04-29T00:24:16.662513+02:00 localhost transmission-daemon[2833]: <Some Torrent> Bad file descriptor (/storage/torrent/download/<Some Torrent>/<Some Torrent file>) (torrent.c:487)
2012-04-29T00:24:16.662524+02:00 localhost transmission-daemon[2833]: Error while flushing completed pieces from cache (session.c:539)
2012-04-29T00:24:16.662534+02:00 localhost transmission-daemon[2833]: Saved "/storage/torrent/.transmission/resume/<Some Torrent>.64458c1cdf9bddd4.resume" (bencode.c:1731)
2012-04-29T00:24:16.662571+02:00 localhost transmission-daemon[2833]: Saved "/storage/torrent/.transmission/stats.json" (bencode.c:1731)
2012-04-29T00:24:16.662642+02:00 localhost transmission-daemon[2833]: <Some Torrent> Pausing (torrent.c:1763)
2012-04-29T00:24:16.662651+02:00 localhost transmission-daemon[2833]: <Some Torrent> write failed for "<Some Torrent>/<Some Torrent file>": Bad file descriptor (inout.c:132)

comment:16 Changed 4 years ago by livings124

  • Version changed from 2.51 to 2.22

comment:17 Changed 4 years ago by karamanolev

  • Cc ivailo@… added
  • Priority changed from Normal to High
  • Version changed from 2.22 to 2.71

I'm using Ubuntu 12.04.01, latest updatesр with Transmission 2.71 and libevent 2.0.20 compiled from source. I'm seeing

[14:15:10.566] <Some Torrent> write failed for "<Some File>": Bad file descriptor (inout.c:132) [14:15:10.566] <Some Torrent> Bad file descriptor (<Some File>) (torrent.c:486)

comment:18 Changed 4 years ago by livings124

  • Priority changed from High to Normal
  • Version changed from 2.71 to 2.22

comment:19 Changed 4 years ago by karamanolev

More feedback on the issue: I strace'd transmission and it turns out that a single torrent in seeding mode was causing downloads to fail. The problem is that Bad file descriptor is reported on downloading torrents, which are unrelated to the torrent that's causing the issue.

strace gave a sequence of:

open() // on a file from that torrent in read-only mode
ftruncate() // on that file, which failed with invalid argument (as expected)
close() // on the file
pwrite() // on the file (bad file descriptor)

The only codepath that can cause such an event of calls is in fdlimit.c / cached_file_open: If writable is false and the size check fails, then it will try to call ftruncate on a file that isn't opened. Something worth noting is that the same torrent passed verify multiple times and verifying it will always say it's at 100%, so transmission things that the file is okay, while apparently being different in size. I've fixed the issue for myself by deleting the offending torrent, but it's a bug in transmission. Also, the error reported wasn't for the right torrent, so only strace-ing it can identify the issue, which is very painful.

comment:20 Changed 4 years ago by eris23

Problem still occurs with Transmission 2.73 (13592) in Ubuntu Quantal amd64, libevent 2.0.19-stable-3.

comment:21 Changed 3 years ago by nialv7

Seriously why is this stupid bug still not fixed?

Someone has already identified the root cause, and a fix won't require more than 10 lines of code!

comment:22 Changed 3 years ago by jordan

  • Milestone changed from None Set to 2.82
  • Resolution set to fixed
  • Status changed from reopened to closed

Mostly because the ticket hadn't been commented on in 8 months and so got lost in the shuffle of other bugs and requests. Thanks for being a squeaky wheel.

r14147: (trunk, libt) #4147 'bad file descriptor': in cached_file_open(), ensure the file is always opened with writable permissions if we need to call ftruncate() to resize it. Large credit to karamanolev for tracking this down with strace.

comment:23 follow-up: Changed 3 years ago by eris23

Problem still occurs with Transmission 2.80 (14103) in Ubuntu Saucy amd64, libevent 2.0.21-stable-1.

comment:24 in reply to: ↑ 23 Changed 3 years ago by jordan

Replying to eris23:

Problem still occurs with Transmission 2.80 (14103) in Ubuntu Saucy amd64, libevent 2.0.21-stable-1.

Does it still occur in r14147 or higher?

comment:25 Changed 3 years ago by x190

---

Last edited 3 years ago by x190 (previous) (diff)

comment:26 Changed 3 years ago by keizie

Transmission-daemon did not move torrent files from ext4 mount point to btrfs mount point, with 'bad file descriptor' error log. Even failed to verify manually-moved torrent files on btrfs mount point. Is this relevant to this ticket? (using transmission-daemon 2.82-0ubuntu1 on ubuntu saucy)

comment:27 Changed 3 years ago by keizie

Former comment made under condition of a) transmission-daemon process is running, b) btrfs filesystem made. After I stop and start transmission-daemon again, move command works. (though I don't get it totally)

Note: See TracTickets for help on using tickets.