Opened 4 years ago

Last modified 3 years ago

#5969 reopened Bug

Transmission crashes with some corrupt torrents with a webseed pointing to a different file than the torrent

Reported by: werrel3 Owned by:
Priority: Normal Milestone: None Set
Component: libtransmission Version: 2.84
Severity: Normal Keywords:
Cc:

Description

The following torrent files cause transmission-qt to crash shortly after downloading starts:

http://torcache.net/torrent/1C3849E273428F9E7C565B313B485A52C4D96832.torrent

crashes after downloading 1.62MB.

http://torcache.net/torrent/A5ABAF6DE67E1EED316D55917F5E1D378162D75A.torrent

crashes after downloading 1.03MB.

Attachments (1)

5969.crash.fix.patch (1.8 KB) - added by x190 3 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 Changed 4 years ago by mike.dld

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

Torrents themselves and webseed links contained point to different files. Will be fixed once #5923 is merged in.

comment:2 Changed 4 years ago by mike.dld

You may want to report this to the person who created these torrents in the meantime.

comment:3 Changed 4 years ago by x190

  • Resolution duplicate deleted
  • Status changed from closed to reopened
  • Summary changed from transmission-qt crashes with some torrents to Transmission crashes with some corrupt torrents
Process:         Transmission [737]
Path:            /Applications/Transmission.app/Contents/MacOS/Transmission
Identifier:      org.m0k.transmission
Version:         2.84+ (14552)
Code Type:       X86-64 (Native)
Parent Process:  launchd [128]

Date/Time:       2015-07-18 10:30:16.201 -0600
OS Version:      Mac OS X 10.6.8 (10K549)
Report Version:  6

Interval Since Last Report:          1338512 sec
Crashes Since Last Report:           4
Per-App Interval Since Last Report:  54 sec
Per-App Crashes Since Last Report:   1
Anonymous UUID:                      E1C1A99F-5B19-46AC-B085-C7F584D3BC74

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread:  2

Application Specific Information:
Assertion failed: (offset < tor->info.totalSize), function tr_ioFindFileLocation, file /Users/transmission/jenkins/workspace/trunk-mac/libtransmission/inout.c, line 181.

Thread 2 Crashed:
0   libSystem.B.dylib             	0x00007fff83e92886 nanosleep$NOCANCEL + 55
1   libSystem.B.dylib             	0x00007fff83eef3ce usleep$NOCANCEL + 57
2   libSystem.B.dylib             	0x00007fff83f0ea00 abort + 93
3   libSystem.B.dylib             	0x00007fff83efb9bc __pthread_markcancel + 0
4   org.m0k.transmission          	0x0000000100075db3 tr_ioFindFileLocation + 286
5   org.m0k.transmission          	0x00000001000949cb connection_succeeded + 122
6   org.m0k.transmission          	0x000000010007c1af readFromPipe + 323
7   org.m0k.transmission          	0x00000001000b6dae event_base_loop + 1827
8   org.m0k.transmission          	0x000000010007bdd6 libeventThreadFunc + 141
9   org.m0k.transmission          	0x00000001000724dd ThreadFunc + 15
10  libSystem.B.dylib             	0x00007fff83e58fd6 _pthread_start + 331
11  libSystem.B.dylib                   0x00007fff83e58e89 thread_start + 13

I think we should reject the torrent, or remove the webseed, rather than allow Transmission to crash. How would #5923 fix this? I haven't tested the torrents with #5923 applied.

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

comment:4 Changed 4 years ago by x190

  • Summary changed from Transmission crashes with some corrupt torrents to Transmission crashes with some corrupt torrents with a webseed pointing to a different file than the torrent

comment:5 follow-up: Changed 4 years ago by mike.dld

#5923 makes Transmission reject the webseed, but not the whole torrent. I think that's good enough.

comment:6 in reply to: ↑ 5 ; follow-up: Changed 4 years ago by x190

Replying to mike.dld:

#5923 makes Transmission reject the webseed, but not the whole torrent. I think that's good enough.

Okay. If it does that before crashing, that's great. I didn't test with the patch applied. Please close the ticket again, if #5923 will do the job. :-)

comment:7 in reply to: ↑ 6 Changed 4 years ago by mike.dld

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

Replying to x190:

Okay. If it does that before crashing, that's great. I didn't test with the patch applied. Please close the ticket again, if #5923 will do the job. :-)

Yeah, that's what I did right before closing the ticket. It doesn't crash. The only side-effect is that it sets the local error for the torrent until it finishes downloading, but I'm okay with that.

comment:8 Changed 4 years ago by cfpp2p

The webseed links contained point to different files and being smaller in size than the correct files. Requesting a range anywhere past the end of the incorrect files returns blocks multiply "We apologize for the delay.There was some delay starting the downloading. Please refresh this page..." enough times to fill the piece and more. This is done without regard for the size of the requested range so that the final blocks of the last piece the amount can exceed the piece and result in total piece offset exceeding torrent total size. That's why the assertion fails in un-patched code.

comment:9 Changed 3 years ago by x190

  • Component changed from Transmission to libtransmission
  • Resolution duplicate deleted
  • Status changed from closed to reopened

comment:10 Changed 3 years ago by x190

[2016-04-30 02:00:41.579]

Note: crash would have occurred here as there was no offset checking done:
[on_content_changed] webseed 0x827400 task 0x40f9a0
index 556 valid 0 task->content 4141 t->length - blocks_done x size 4084 code 0

[web_response] webseed 0x827400 task 0x40f9a0 status 9 task_flag 9 code 206

Note: We are now in web_response_func () and the task and data will be freed:
[tr_file_is_valid_offset 0] webseed 0x827400 task 0x40f9a0 
piece_index 556 t->content 4141 t->length - blocks_done x size 4084 code 206

"tr_file_is_valid_offset 0' indicates where a crash would have occurred.

Data will be properly freed in web_response_func ():

tr_list_remove_data (&w->tasks, t);
evbuffer_free (t->content);
tr_free (t);

Without the attached patch you will get the tr_ioFindFileLocation () assert crash plus, if the code gets into web_response func (), there is potential for giving negative values to unsigned integer variables.

See also: #5923 and #6110.

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

Changed 3 years ago by x190

Note: See TracTickets for help on using tickets.