Opened 15 years ago

Closed 15 years ago

#836 closed Bug (fixed)

Random crash if torrent source inaccessible

Reported by: foxntd Owned by: charles
Priority: Normal Milestone: None Set
Component: GTK+ Client Version: 1.10
Severity: Normal Keywords:


There is an issue with Transmission (GTK+ client 1.10 from source) that can cause the program to crash (abruptly exit); launching the program from the command line will show the output when the crash occurs, if it occurs. The output is a stack trace about corruption in a doubly-linked list.

The problem is based on the following scenario: If you re-open Transmission and there is a torrent already listed since it was already used and paused in a previous session, and that torrent is located somewhere that is no longer accessible, such as a directory without permissions or, in my test case, on a partition that hasn't been mounted to its mount point yet, then attempting to resume the torrent will appear normal for a moment, until it aborts the transfer with a simple "Permission denied" statement. (I would suggest revision for this message because it gives the user the impression that the tracker is denying them permission when it's actually an error from the OS causing the problem.)

I could not find a way to reliably reproduce the complete crash of the application; it appears to occur at random.

Furthermore, if you enable a download cap to 0 KB/s and attempt to seed, the torrent session doesn't even fail, it idles with 0 KB/s upload and does not abort; essentially, it does not realize there is no data to seed with.

Apparently the following are missing:

1) Transmission needs to check the torrent is still where it once was before trying to resume a torrent session. Also it should check that the data destination also exists, otherwise it should not be attempting to resume. Not only does the above problem occur, but the program "forgets" what data has already accumulated (although Verify Local Data can recover from this.)

2) If the data is not accessible, the program shouldn't be "seeding nothing". I think that solving the above will prevent this from happening as well.

Change History (2)

comment:1 Changed 15 years ago by charles

  • Component changed from Transmission to GTK+ Client
  • Owner set to charles

comment:2 Changed 15 years ago by charles

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

Thanks for the bug report!

The "permission denied" error message you describe is fixed in and backported to the 1.1x branch in r5504.

The double memory free was fixed in trunk in r5333 and backported to the 1.1x branch in r5494.

The download-seed-of-zero-kills-upload-speed issue has been discussed before at .

Note: See TracTickets for help on using tickets.