Opened 7 years ago

Closed 7 years ago

#4687 closed Bug (fixed)

magnet link behaves oddly

Reported by: cfpp2p Owned by:
Priority: Normal Milestone: 2.50
Component: Transmission Version: 2.42
Severity: Normal Keywords:
Cc:

Description

magnet link behaves oddly

Attached magnet links start then suddenly stop downloading without reason to 0 speed. Same downloads via .torrent download OK.

Attachments (6)

torrent-tests.zip (59.9 KB) - added by cfpp2p 7 years ago.
vmag.zip (88.4 KB) - added by cfpp2p 7 years ago.
v1.JPG (10.8 KB) - added by cfpp2p 7 years ago.
v2.JPG (11.0 KB) - added by cfpp2p 7 years ago.
v3.JPG (6.0 KB) - added by cfpp2p 7 years ago.
v4.JPG (10.0 KB) - added by cfpp2p 7 years ago.

Download all attachments as: .zip

Change History (21)

Changed 7 years ago by cfpp2p

comment:1 Changed 7 years ago by x190

My testing appears to indicate that VODO only supports .torrents downloaded from them, i.e. those containing the "vodo / created with libv2v for vodo" message. Transmission 2.42+ (13112) does not handle this well at all in the case of the provided magnet links. The Mac Client will consistently crash soon after starting to download due to handshake issues.

Thread 2 Crashed:
0   org.m0k.transmission_Env_Var  	0x00000001000776f9 tr_peerIoGetAddress + 9
1   org.m0k.transmission_Env_Var  	0x000000010008054f handshakeCompareToAddr + 16
2   org.m0k.transmission_Env_Var  	0x00000001000732ac tr_ptrArrayLowerBound + 103
3   org.m0k.transmission_Env_Var  	0x00000001000733af tr_ptrArrayFindSorted + 22
4   org.m0k.transmission_Env_Var  	0x000000010007fc31 peerIsInUse + 67
5   org.m0k.transmission_Env_Var  	0x000000010007e9e3 atomPulse + 252
6   org.m0k.transmission_Env_Var  	0x00000001000a59ad event_base_loop + 686
7   org.m0k.transmission_Env_Var  	0x0000000100073598 libeventThreadFunc + 145
8   org.m0k.transmission_Env_Var  	0x0000000100068872 ThreadFunc + 15
9   libSystem.B.dylib             	0x00007fff87990fd6 _pthread_start + 331
10  libSystem.B.dylib             	0x00007fff87990e89 thread_start + 13

Thread 2 Crashed:
0   libSystem.B.dylib             	0x00007fff879ca9ce __semwait_signal_nocancel + 10
1   libSystem.B.dylib             	0x00007fff879ca8d0 nanosleep$NOCANCEL + 129
2   libSystem.B.dylib             	0x00007fff87a273ce usleep$NOCANCEL + 57
3   libSystem.B.dylib             	0x00007fff87a46a00 abort + 93
4   libSystem.B.dylib             	0x00007fff87a339bc __pthread_markcancel + 0
5   org.m0k.transmission_Env_Var  	0x000000010007775c tr_peerIoAddrStr + 0
6   org.m0k.transmission_Env_Var  	0x000000010008054f handshakeCompareToAddr + 16
7   org.m0k.transmission_Env_Var  	0x00000001000732ac tr_ptrArrayLowerBound + 103
8   org.m0k.transmission_Env_Var  	0x00000001000733af tr_ptrArrayFindSorted + 22
9   org.m0k.transmission_Env_Var  	0x000000010007fc31 peerIsInUse + 67
10  org.m0k.transmission_Env_Var  	0x000000010007f3ea bandwidthPulse + 2074
11  org.m0k.transmission_Env_Var  	0x00000001000a59ad event_base_loop + 686
12  org.m0k.transmission_Env_Var  	0x0000000100073598 libeventThreadFunc + 145
13  org.m0k.transmission_Env_Var  	0x0000000100068872 ThreadFunc + 15
14  libSystem.B.dylib             	0x00007fff87990fd6 _pthread_start + 331
15  libSystem.B.dylib             	0x00007fff87990e89 thread_start + 13

Application Specific Information: Assertion failed: (tr_isPeerIo( io )), function tr_peerIoGetAddress, file /Users/transmission/hudson/workspace/trunk-mac/trunk/libtransmission/peer-io.c, line 860.

Here's a third crash obtained by pausing the de-magnetized transfer before it could crash by itself.

Thread 2 Crashed:
0   org.m0k.transmission_Env_Var  	0x000000010007779f tr_peerIoSetIOFuncs + 4
1   org.m0k.transmission_Env_Var  	0x000000010007462b tr_handshakeDone + 108
2   org.m0k.transmission_Env_Var  	0x000000010007c885 stopTorrent + 136
3   org.m0k.transmission_Env_Var  	0x0000000100065180 stopTorrent + 130
4   org.m0k.transmission_Env_Var  	0x00000001000738d5 readFromPipe + 274
5   org.m0k.transmission_Env_Var  	0x00000001000a59ad event_base_loop + 686
6   org.m0k.transmission_Env_Var  	0x0000000100073598 libeventThreadFunc + 145
7   org.m0k.transmission_Env_Var  	0x0000000100068872 ThreadFunc + 15
8   libSystem.B.dylib             	0x00007fff87990fd6 _pthread_start + 331
9   libSystem.B.dylib             	0x00007fff87990e89 thread_start + 13


EDIT: cfpp2p: May I ask where these (magnet) links came from?

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

comment:2 follow-up: Changed 7 years ago by gunzip

that magnet link also crashes transmission-daemon 2.42+ (13113) in Linux Debian:

peer-io.c:860: tr_peerIoGetAddress: Assertion `tr_isPeerIo( io )' failed.

full gdb backtrace here: http://pastebin.com/jwKt0Eaf

just for info, that same magnet link worked fine in another bittorrent client, aria2.

Changed 7 years ago by cfpp2p

comment:3 in reply to: ↑ 2 ; follow-up: Changed 7 years ago by x190

Replying to gunzip:

just for info, that same magnet link worked fine in another bittorrent client, aria2.

Okay, but what happens when you pause and restart the torrent? I get a "Unauthorized torrent" message when I do that (if it doesn't crash). I can get cfpp2p's provided link to work without crashing or error by changing the "+" signs to ".", until I pause the torrent.

magnet:?xt=urn:btih:24ad1d85206db5f85491a690e6723e27f4551e01&dn=Zenith.Part.1.2011.Xvid-VODO&tr=http://tracker.vodo.net:6970/announce

My guess is that once vodo realizes the torrent is not d/led from their site , they are deliberately sabotaging the handshake process (their server must be one of the connected peers).

Here's my last crash report (for good measure). I quess Transmission s/b able to handle this without crashing?

Application Specific Information:
Assertion failed: (ours), function myHandshakeDoneCB, file /Users/transmission/hudson/workspace/trunk-mac/trunk/libtransmission/peer-mgr.c, line 1969.

Thread 2 Crashed:
0   libSystem.B.dylib             	0x00007fff879ca9ce __semwait_signal_nocancel + 10
1   libSystem.B.dylib             	0x00007fff879ca8d0 nanosleep$NOCANCEL + 129
2   libSystem.B.dylib             	0x00007fff87a273ce usleep$NOCANCEL + 57
3   libSystem.B.dylib             	0x00007fff87a46a00 abort + 93
4   libSystem.B.dylib             	0x00007fff87a339bc __pthread_markcancel + 0
5   org.m0k.transmission_Env_Var  	0x000000010007b1c3 myHandshakeDoneCB + 1172
6   org.m0k.transmission_Env_Var  	0x00000001000746bd tr_handshakeDone + 254
7   org.m0k.transmission_Env_Var  	0x000000010007677d gotError + 469
8   org.m0k.transmission_Env_Var  	0x0000000100078bd6 tr_peerIoFlush + 924
9   org.m0k.transmission_Env_Var  	0x000000010008c751 tr_bandwidthAllocate + 139
10  org.m0k.transmission_Env_Var  	0x000000010007ec7b bandwidthPulse + 171
11  org.m0k.transmission_Env_Var  	0x00000001000a59ad event_base_loop + 686
12  org.m0k.transmission_Env_Var  	0x0000000100073598 libeventThreadFunc + 145
13  org.m0k.transmission_Env_Var  	0x0000000100068872 ThreadFunc + 15
14  libSystem.B.dylib             	0x00007fff87990fd6 _pthread_start + 331
15  libSystem.B.dylib             	0x00007fff87990e89 thread_start + 13

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

Changed 7 years ago by cfpp2p

Changed 7 years ago by cfpp2p

Changed 7 years ago by cfpp2p

Changed 7 years ago by cfpp2p

comment:4 Changed 7 years ago by cfpp2p

VODO only supports .torrents downloaded from them, i.e. those containing the "vodo / created with libv2v for vodo" message.

attach another VODO magnet link no problems and the resulting metafile retrieved and having no 'vodo / created with libv2v for vodo' contained still works perfectly. Hmmmm?

all 2.42+ (13113)

your correct, the other torrents do contain the vodo message.

private feed of links, sent to me act corrupt but I think transmission shouldn't behave to freeze-lock or crash.

comment:5 Changed 7 years ago by cfpp2p

(their server must be one of the connected peers)

confirmed, .JPGs attached

other clients can pause then restart without getting the "Unauthorized torrent"

transmission shouldn't crash

comment:6 in reply to: ↑ 3 ; follow-up: Changed 7 years ago by gunzip

Replying to x190:

Okay, but what happens when you pause and restart the torrent? I get a "Unauthorized torrent" message when I do that (if it doesn't crash). I can get cfpp2p's provided link to work without crashing or error by changing the "+" signs to ".", until I pause the torrent.

magnet:?xt=urn:btih:24ad1d85206db5f85491a690e6723e27f4551e01&dn=Zenith.Part.1.2011.Xvid-VODO&tr=http://tracker.vodo.net:6970/announce

My guess is that once vodo realizes the torrent is not d/led from their site , they are deliberately sabotaging the handshake process (their server must be one of the connected peers).

It crashed for me soon after the metadata was obtained, regardless of whether i paused it or not. I also tried changing the + to - but still no luck.

I not worried about the tracker error message, but it would be alarming if one peer could sabotage a torrent by causing other clients to crash. The fact that another client (aria2) has no such crashing problem leads me to believe that there is some unknown transmission bug.

comment:7 in reply to: ↑ 6 Changed 7 years ago by x190

Replying to gunzip:

Replying to x190:

... it would be alarming if one peer could sabotage a torrent by causing other clients to crash.

Yes, I agree 100%. VODO can refuse to supply peers if they want but disconnecting or otherwise messing up the handshake shouldn't cause Transmission to crash.

Application Specific Information: Assertion failed: (tr_isPeerIo( io )), function tr_peerIoGetAddress, file /Users/transmission/hudson/workspace/trunk-mac/trunk/libtransmission/peer-io.c, line 860. 
Application Specific Information:
Assertion failed: (ours), function myHandshakeDoneCB, file /Users/transmission/hudson/workspace/trunk-mac/trunk/libtransmission/peer-mgr.c, line 1969.

comment:8 Changed 7 years ago by livings124

  • Version changed from 2.42+ to 2.42

comment:9 Changed 7 years ago by cfpp2p

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

fixed with patch at ticket #4689

comment:10 Changed 7 years ago by livings124

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:11 Changed 7 years ago by cfpp2p

  • Milestone changed from None Set to 2.50

comment:12 Changed 7 years ago by x190

worksforme. :-) Nice sleuthing and coding. I salute you, Sir cfpp2p!

comment:13 Changed 7 years ago by gunzip

nice work cfpp2p, your patch also solved the crashing problem on my end.

comment:14 Changed 7 years ago by jordan

FWIW, here's a better trace:

==19263== Invalid read of size 4
==19263==    at 0x80EA74D: tr_handshakeGetAddr (handshake.c:1246)
==19263==    by 0x80CE334: handshakeCompareToAddr (peer-mgr.c:290)
==19263==    by 0x809CA37: tr_ptrArrayLowerBound (ptrarray.c:136)
==19263==    by 0x809CBCA: tr_ptrArrayFindSorted (ptrarray.c:202)
==19263==    by 0x80CE3A5: getExistingHandshake (peer-mgr.c:305)
==19263==    by 0x80CE550: peerIsInUse (peer-mgr.c:368)
==19263==    by 0x80D5FF9: isPeerCandidate (peer-mgr.c:3743)
==19263==    by 0x80D6ADB: getPeerCandidates (peer-mgr.c:3986)
==19263==    by 0x80D6E9E: makeNewPeerConnections (peer-mgr.c:4079)
==19263==    by 0x80D584D: reconnectPulse (peer-mgr.c:3521)
==19263==    by 0x80D5AF4: bandwidthPulse (peer-mgr.c:3607)
==19263==    by 0x48F6CE8: event_base_loop (in /usr/lib/libevent-2.0.so.5.1.4)
==19263==    by 0x48F7A82: event_base_dispatch (in /usr/lib/libevent-2.0.so.5.1.4)
==19263==    by 0x809B9B1: ThreadFunc (platform.c:118)
==19263==    by 0x4B78C86: start_thread (pthread_create.c:304)
==19263==    by 0x4C6168D: clone (clone.S:130)
==19263==  Address 0x64490ec is 4 bytes inside a block of size 168 free'd
==19263==    at 0x402906C: free (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==19263==    by 0x80BA518: tr_free (utils.c:348)
==19263==    by 0x80EA0B1: tr_handshakeFree (handshake.c:1087)
==19263==    by 0x80EA15C: tr_handshakeDone (handshake.c:1100)
==19263==    by 0x80EA42A: gotError (handshake.c:1165)
==19263==    by 0x8099419: utp_on_error (peer-io.c:487)
==19263==    by 0x80F5334: UTPSocket::check_timeouts() (utp.cpp:1299)
==19263==    by 0x80F86D1: UTP_CheckTimeouts (utp.cpp:2775)
==19263==    by 0x80B96AC: timer_callback (tr-utp.c:160)
==19263==    by 0x48F6CE8: event_base_loop (in /usr/lib/libevent-2.0.so.5.1.4)
==19263==    by 0x48F7A82: event_base_dispatch (in /usr/lib/libevent-2.0.so.5.1.4)
==19263==    by 0x809B9B1: ThreadFunc (platform.c:118)
==19263==    by 0x4B78C86: start_thread (pthread_create.c:304)
==19263==    by 0x4C6168D: clone (clone.S:130)

Vodo isn't sabotaging the process. What's happening is that their .torrent's info dictionary contains a bencoded dictionary-within-a-dictionary, which is a use case libtransmission's dictionary merge code hadn't been designed to handle. This meant that part of the metadata was different, so the torrent's checksum changed.

that I hadn't seen before and that our benc merge code wasn't designed to handle... so that nested dictionary was omitted from the merge, which unfortunately caused the torrent's metadata's checksum to change. The Peer Manager was using that checksum as a lookup key for its internal table of outbound handshake attempts, so when an attempt failed and its memory was freed, the attempt wasn't removed from the Peer Manager's tables, so the tables' entries contained dangling pointers.

cfpp2p's patch solves this use case nicely by always adding the nested dict whenever merging two dictionaries together and the source has a nested dictionary itself. However, tr_bencDictMerge() is meant to be a general purpose function, and it's not clear to me that is the correct behavior every time. For example, what if the target dictionary has its own nested dictionary with the same key? Ideally we would merge those two children together, rather than one overwriting the other.

So, here's my variation on cfpp2p's fix:

else if( tr_bencIsDict( val ) )
{
    tr_benc * target_dict = tr_bencDictFind( target, key );

    if( target_dict == NULL )
        target_dict = tr_bencDictAddDict( target, key, tr_bencDictSize( val ) );

    if( tr_bencIsDict( target_dict ) )
        tr_bencMergeDicts( target_dict, val );
}

This way, we'll Do the Right Thing if the target has no child with that name, or if the child is a dictionary.

comment:15 Changed 7 years ago by jordan

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

Fixed for 2.50 by r13198.

Note: See TracTickets for help on using tickets.