Charles Kerr [Sun, 10 Jan 2010 19:52:01 +0000 (19:52 +0000)]
(trunk libT) #2416 "crash in event_queue_insert" -- I think this is happening if we queue up two changes, one to listen for read/write, and then a second one to delete the polling, in kqueue's event mechanism, at libcurl's request. Let's try disabling kqueue in libevent and use poll/select instead.
Charles Kerr [Sun, 10 Jan 2010 08:53:17 +0000 (08:53 +0000)]
(trunk libT) #2416 "crash in event_queue_insert" -- another guess, based on the idea that we might queue two actions (one to insert, one to delete) on the same event before libevent's dispatcher is invoked
Charles Kerr [Fri, 8 Jan 2010 21:45:56 +0000 (21:45 +0000)]
(trunk libT) #2416 "crash in event_queue_insert" -- continue throwing the kitchen sink at this ticket. (1) disable proxies to see if that makes any difference (2) rearrange the sequencing in sock_cb() to unconditionally delete the active event before doing anything else (3) use a libevent timer instead of CURLOPT_TIMEOUT to workaround curl bug http://tinyurl.com/ycm5d3e
Charles Kerr [Tue, 29 Dec 2009 00:00:33 +0000 (00:00 +0000)]
(trunk libT) #2416 "crash in event_queue_insert" -- I am really quite sick of this bug. It's not reproducible at all under Linux and appears to be a bug in libevent's kqueue implementation. In this commit, we leak the event object on OS X.
Charles Kerr [Mon, 28 Dec 2009 23:25:50 +0000 (23:25 +0000)]
(trunk libT) fix minor bug in r9651 "Reduce SO_SNDBUF and SO_RCVBUF for tracker announce/scrape messages" -- libcurl's CURLOPT_SOCKOPTFUNCTION doesn't return void; it returns an int that is nonzero if an error occurs.
Charles Kerr [Mon, 28 Dec 2009 23:24:00 +0000 (23:24 +0000)]
(trunk libT) fix minor bug in r9651 "Reduce SO_RCVBUF for outgoing peer connections on seeding torrents" -- remember the "isSeed" attribute so that we can use it on reconnects
Charles Kerr [Thu, 24 Dec 2009 18:50:34 +0000 (18:50 +0000)]
(trunk libT) #2416 "crash in event_queue_insert" -- another experimental commit. /as an experiment/ let's just leak that event struct and see if that makes the crash go away. Obviously leaking those objects is not a long term fix but this will help point the way towards the real fix.
Charles Kerr [Thu, 24 Dec 2009 18:01:48 +0000 (18:01 +0000)]
(trunk libT) #2632 "Add streaming capability to libtransmission (but not the Transmission GUI clients)" -- revert this feature due to pushback from devs and users and the 1.80 freeze
Charles Kerr [Wed, 23 Dec 2009 16:44:10 +0000 (16:44 +0000)]
(trunk gtk) add a little more height to the "edit trackers" dialog... right now it's so short that any more than two or three trackers look squashed in the dialog
Charles Kerr [Wed, 23 Dec 2009 16:12:18 +0000 (16:12 +0000)]
(trunk libT) #2416 "crash in event_queue_insert" -- possible fix. it looks like the kqueue client is accessing the event after the callback and after event_del() is being called. *If* that's the case I don't know if it's a libevent bug or if libtransmission is making assumptions it shouldn't've... but it's easy enough to keep the memory in a pool and free it later when it's safer to do so.
Charles Kerr [Fri, 18 Dec 2009 17:32:16 +0000 (17:32 +0000)]
(trunk libT) it certainly smells like we're using freed memory in the libcurl + libevent code in web.c... let's trash the structures right before free()ing them
Charles Kerr [Wed, 16 Dec 2009 18:20:01 +0000 (18:20 +0000)]
(trunk) #2548 "T's request queue can send out too many duplicate requests" -- (1) fix r9465 implementation bug that caused some peers to get starved of requests if they rejected a request or choked, then unchoked us. (2) increase a block request's TTL by 15 seconds to reduce cancel/req cycles between two or more blocks (3) add a debug mode to the GTK+ client's peer tab to watch the pending requests counts both up & down