Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#5379 closed Bug (fixed)

Transmission could encounter crash in packet processing code.

Reported by: pathetic_loser Owned by: jordan
Priority: High Milestone: 2.80
Component: Transmission Version: 2.77
Severity: Critical Keywords: crash packet processing
Cc:

Description

Configuration:

Xubuntu 13.04, 64-bit. GTK+ client - latest trunk (revision 14085).

To reproduce:

For me it's enough to try to download Xonotic 0.7 (opensource game) torrent (http://dl.xonotic.org/xonotic-0.7.0.zip.torrent). Then transmission would crash at about 70-90% of file downloaded. Could be subject to network conditions though.

Backtrace follows: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fb6fbfff700 (LWP 7838)] 0x00000000004a0101 in tr_peerMsgsCancel (msgs=0x0, block=22327) at peer-msgs.c:889 889 blockToReq (msgs->torrent, block, &req); (gdb) bt #0 0x00000000004a0101 in tr_peerMsgsCancel (msgs=0x0, block=22327) at peer-msgs.c:889 #1 0x000000000049824c in cancelAllRequestsForBlock (s=0x1ceec80, block=22327, no_notify=0x7fb6f0adbf70) at peer-mgr.c:1675 #2 0x0000000000498727 in peerCallbackFunc (peer=0x7fb6f0adbf70, e=0x7fb6fbffd620, vs=0x1ceec80) at peer-mgr.c:1819 #3 0x000000000049f561 in publish (msgs=0x7fb6f0adbf70, e=0x7fb6fbffd620) at peer-msgs.c:482 #4 0x000000000049f633 in fireGotBlock (msgs=0x7fb6f0adbf70, req=0x7fb6f0ade8a8) at peer-msgs.c:502 #5 0x00000000004a2961 in clientGotBlock (msgs=0x7fb6f0adbf70, data=0x7fb6f05bfe30, req=0x7fb6f0ade8a8) at peer-msgs.c:1706 #6 0x00000000004a1ba9 in readBtPiece (msgs=0x7fb6f0adbf70, inbuf=0x7fb6f04e7260, inlen=1382, setme_piece_bytes_read=0x7fb6fbffd7c8) at peer-msgs.c:1446 #7 0x00000000004a2a91 in canRead (io=0x7fb6f1309e10, vmsgs=0x7fb6f0adbf70, piece=0x7fb6fbffd7c8) at peer-msgs.c:1740 #8 0x0000000000491a40 in canReadWrapper (io=0x7fb6f1309e10) at peer-io.c:206 #9 0x00000000004924eb in utp_on_read (closure=0x7fb6f1309e10,

buf=0x7fb6fbffdb24 "2I\216y\f\324o&\347Tӣ\211\374\021\371\342cF\223\214\273\356f\004\262u\030퐫\242\224v\303R\362\060\002$:굿r\213\227\201e\325\035\367~\375\354k\217܉\247\035\a!-|\366\370Ty\202;\213gy\234\016\335\372ΚR;\273\212\277\351\303|", buflen=1382) at peer-io.c:427

#10 0x00000000004c8a48 in UTP_ProcessIncoming (conn=0x7fb6f055abb0, packet=0x7fb6fbffdb10 "\001", len=1402, syn=false) at utp.cpp:2158 #11 0x00000000004c9ccb in UTP_IsIncomingUTP (incoming_proc=0x46fb5c <incoming>, send_to_proc=0x46fcaa <tr_utpSendTo>, send_to_userdata=0x188b000, buffer=0x7fb6fbffdb10 "\001", len=1402,

to=0x7fb6fbffda90, tolen=16) at utp.cpp:2587

#12 0x000000000046fea8 in tr_utpPacket (buf=0x7fb6fbffdb10 "\001", buflen=1402, from=0x7fb6fbffda90, fromlen=16, ss=0x188b000) at tr-utp.c:180 #13 0x000000000046f655 in event_callback (s=18, type=2, sv=0x188b000) at tr-udp.c:226 #14 0x00007fb70ea65744 in event_base_loop () from /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5 #15 0x0000000000470233 in libeventThreadFunc (veh=0x1888d50) at trevent.c:249 #16 0x0000000000451679 in ThreadFunc? (_t=0x1889d30) at platform.c:152 #17 0x00007fb70dcdff8e in start_thread (arg=0x7fb6fbfff700) at pthread_create.c:311 #18 0x00007fb70da09e1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113

(gdb) bt full #0 0x00000000004a0101 in tr_peerMsgsCancel (msgs=0x0, block=22327) at peer-msgs.c:889

req = {index = 4870814, offset = 0, length = 30501440}

#1 0x000000000049824c in cancelAllRequestsForBlock (s=0x1ceec80, block=22327, no_notify=0x7fb6f0adbf70) at peer-mgr.c:1675

p = 0x1d16a40 i = 0 peerCount = 2 peers = 0x7fb6af0274f0 peerArr = {items = 0x7fb6af0274f0, n_items = 2, n_alloc = 32}

#2 0x0000000000498727 in peerCallbackFunc (peer=0x7fb6f0adbf70, e=0x7fb6fbffd620, vs=0x1ceec80) at peer-mgr.c:1819

tor = 0x1d16000 p = 348 block = 22327 s = 0x1ceec80 PRETTY_FUNCTION = "peerCallbackFunc"

#3 0x000000000049f561 in publish (msgs=0x7fb6f0adbf70, e=0x7fb6fbffd620) at peer-msgs.c:482 No locals. #4 0x000000000049f633 in fireGotBlock (msgs=0x7fb6f0adbf70, req=0x7fb6f0ade8a8) at peer-msgs.c:502

e = {eventType = TR_PEER_CLIENT_GOT_BLOCK, pieceIndex = 348, bitfield = 0x0, offset = 901120, length = 16384, err = 0, port = 0}

#5 0x00000000004a2961 in clientGotBlock (msgs=0x7fb6f0adbf70, data=0x7fb6f05bfe30, req=0x7fb6f0ade8a8) at peer-msgs.c:1706

err = 0 tor = 0x1d16000 block = 22327 PRETTY_FUNCTION = "clientGotBlock"

#6 0x00000000004a1ba9 in readBtPiece (msgs=0x7fb6f0adbf70, inbuf=0x7fb6f04e7260, inlen=1382, setme_piece_bytes_read=0x7fb6fbffd7c8) at peer-msgs.c:1446

err = 0 n = 461 nLeft = 461 block_buffer = 0x7fb6f05bfe30 req = 0x7fb6f0ade8a8 PRETTY_FUNCTION = "readBtPiece"

#7 0x00000000004a2a91 in canRead (io=0x7fb6f1309e10, vmsgs=0x7fb6f0adbf70, piece=0x7fb6fbffd7c8) at peer-msgs.c:1740

ret = (READ_ERR | unknown: 32692) msgs = 0x7fb6f0adbf70 in = 0x7fb6f04e7260 inlen = 1382 PRETTY_FUNCTION = "canRead"

#8 0x0000000000491a40 in canReadWrapper (io=0x7fb6f1309e10) at peer-io.c:206

oldLen = 1382 ret = -67119120 overhead = 32694 piece = 461 used = 562949953421312 now = 1370774010768 err = false done = false session = 0x188b000 PRETTY_FUNCTION = "canReadWrapper"

#9 0x00000000004924eb in utp_on_read (closure=0x7fb6f1309e10,

buf=0x7fb6fbffdb24 "2I\216y\f\324o&\347Tӣ\211\374\021\371\342cF\223\214\273\356f\004\262u\030퐫\242\224v\303R\362\060\002$:굿r\213\227\201e\325\035\367~\375\354k\217܉\247\035\a!-|\366\370Ty\202;\213gy\234\016\335\372ΚR;\273\212\277\351\303|", buflen=1382) at peer-io.c:427

rc = 0 io = 0x7fb6f1309e10 PRETTY_FUNCTION = "utp_on_read"

#10 0x00000000004c8a48 in UTP_ProcessIncoming (conn=0x7fb6f055abb0, packet=0x7fb6fbffdb10 "\001", len=1402, syn=false) at utp.cpp:2158

count = 1382 packet_end = 0x7fb6fbffe08a "\236\216H\262D\200\350\366\224R", <incomplete sequence \347> PRETTY_FUNCTION = "size_t UTP_ProcessIncoming(UTPSocket*, const byte*, size_t, bool)" min_rtt = 9223372036854775807 prev_delay_base = 2007691772

---Type <return> to continue, or q <return> to quit---

pk_ack_nr = 99 time = 258257887282 their_delay = 2287340165 pf = 0x7fb6fbffdb10 pf1 = 0x7fb6fbffdb10 selack_ptr = 0x0 data = 0x7fb6fbffdb24 "2I\216y\f\324o&\347Tӣ\211\374\021\371\342cF\223\214\273\356f\004\262u\030퐫\242\224v\303R\362\060\002$:굿r\213\227\201e\325\035\367~\375\354k\217܉\247\035\a!-|\366\370Ty\202;\213gy\234\016\335\372ΚR;\273\212\277\351\303|" extension = 0 seqnr = 0 acks = 0 actual_delay = 2007755553 pk_seq_nr = 38053 pk_flags = 0 '\000' acked_bytes = 0 p = 2567476653

#11 0x00000000004c9ccb in UTP_IsIncomingUTP (incoming_proc=0x46fb5c <incoming>, send_to_proc=0x46fcaa <tr_utpSendTo>, send_to_userdata=0x188b000, buffer=0x7fb6fbffdb10 "\001", len=1402,

to=0x7fb6fbffda90, tolen=16) at utp.cpp:2587

read = 1382 conn = 0x7fb6f055abb0 i = 10 pf = 0x7fb6fbffdb10 pf1 = 0x7fb6fbffdb10 flags = 0 '\000' seq_nr = 0 addr = {_in = {_in6 = "\000\000\000\000\000\000\000\000\000\000\377\377T\371s\227", _in6w = {0, 0, 0, 0, 0, 65535, 63828, 38771}, _in6d = {0, 0, 4294901760, 2540960084}, _in6addr = {

in6_u = {u6_addr8 = "\000\000\000\000\000\000\000\000\000\000\377\377T\371s\227", u6_addr16 = {0, 0, 0, 0, 0, 65535, 63828, 38771}, u6_addr32 = {0, 0, 4294901760,

2540960084}}}}, _port = 51413}

p = 0x7fb6fbffdb10 p1 = 0x7fb6fbffdb10 version = 1 '\001' id = 42732

#12 0x000000000046fea8 in tr_utpPacket (buf=0x7fb6fbffdb10 "\001", buflen=1402, from=0x7fb6fbffda90, fromlen=16, ss=0x188b000) at tr-utp.c:180 No locals. #13 0x000000000046f655 in event_callback (s=18, type=2, sv=0x188b000) at tr-udp.c:226

rc = 1402 fromlen = 16 buf = "\001\000\246\354\231\b\225\255w\253\353!\000\004\000\000\224\245\000c2I\216y\f\324o&\347Tӣ\211\374\021\371\342cF\223\214\273\356f\004\262u\030퐫\242\224v\303R\362\060\002$:굿r\213\227\201e\325\035\367~\375\354k\217܉\247\035\a!-|\366\370Ty\202;\213gy\234\016\335\372ΚR;\273\212\277\351\303|\000\356ّ\207\375\253+s\241\243\364\277\343\366\233\255\240\071\002<m\213(\335\017\023\266爅\232\340\005,P\356\231\006m\273D\372:\251̵\322uf-\032q~M\272\006DŽS\241M\t\371\363\366\225e\240dO}F9\314\032\376:\266\025rt
ʪ\320\366o\334\361\264믧\021]2-'x\036\002\315\327o\222"... from = {ss_family = 2, ss_align = 0,

ss_padding = "\375\377\377\377\377\377\377\377\000\000\000\000\000\000\000\000d\272\034\302\004\034\327D\256", '\000' <repeats 11 times>, "\n", '\000' <repeats 19 times>, "\065\340\377\373\266\177\000\000`\341\377\373\266\177\000\000P\341\377\373\266\177\000\000\256\022N\000\000\000\000\000\265\022N\000\000\000\000\000\030\343\377\373\266\177\000\000B\231\225\r\267\177\000"}

ss = 0x188b000 PRETTY_FUNCTION = "event_callback"

#14 0x00007fb70ea65744 in event_base_loop () from /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5 No symbol table info available. #15 0x0000000000470233 in libeventThreadFunc (veh=0x1888d50) at trevent.c:249

base = 0x7fb6f00008f0 eh = 0x1888d50

#16 0x0000000000451679 in ThreadFunc? (_t=0x1889d30) at platform.c:152

t = 0x1889d30

#17 0x00007fb70dcdff8e in start_thread (arg=0x7fb6fbfff700) at pthread_create.c:311

res = <optimized out> pd = 0x7fb6fbfff700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140423888631552, -5434880816306837058, 0, 140424231759968, 140424187385664, 4096, 5475984958446250430, 5475663747007392190}, mask_was_saved = 0}},

priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}

not_first_call = 0

---Type <return> to continue, or q <return> to quit---

pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> PRETTY_FUNCTION = "start_thread"

#18 0x00007fb70da09e1d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113 No locals.

Change History (5)

comment:1 Changed 8 years ago by jordan

  • Milestone changed from None Set to 2.80
  • Owner set to jordan
  • Status changed from new to assigned
  • Version changed from 2.77+ to 2.77

Looks like it's failing to distinguish the difference between connections to webseeds and to bittorrent peers, and is trying to send a BT cancel message to the former. *facepalm*

comment:2 Changed 8 years ago by jordan

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

Fixed in r14088

comment:3 Changed 8 years ago by pathetic_loser

and is trying to send a BT cancel message to the former. *facepalm*

Wow. I've got idea it crashes when trying to do something with cancel messages. But I lacked enough imagination to assume THIS behavior... O_O

comment:4 Changed 8 years ago by jordan

It's coming from the half-assed retrofit I did of the peers struct. web peers and bt peers are now sort-of sibling subclasses of tr_peer, but of course libtransmission is in C and rolls its own class mechanisms.

Ideally this would be rerolled into C++, or at least a more rigid class mechanism.

But I lacked enough imagination to assume THIS behavior... O_O

Dream big! :)

comment:5 Changed 8 years ago by pathetic_loser

It reminds me one ~15 year old history about kangaroos and stingers - http://www.snopes.com/humor/nonsense/kangaroo.asp :).

Note: See TracTickets for help on using tickets.