Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#2781 closed Bug (fixed)

Transmission 1.80 suspends at the start

Reported by: 4rG Owned by: charles
Priority: Normal Milestone: 1.81
Component: Transmission Version: 1.80
Severity: Major Keywords:
Cc: jch@…

Description (last modified by charles)

I have upgraded transmission from 1.76 to 1.80, then problem begins. It works 2-5s and then i need to kill application.

freeze report:

Change History (13)

comment:1 Changed 12 years ago by charles

Wow, trac's messed-up formatting makes that nearly unreadable.

Pastebinned here:

comment:2 Changed 12 years ago by charles

  • Description modified (diff)

comment:3 Changed 12 years ago by charles

I think the cause behind this is that libcurl is blocking in calls to getaddrinfo()... at least, that's what's causing it on my Linux system. I've got an experimental fix for this in r9990 and r9991. It would be good if Mac users could give this a test to see if this fixes it on OS X as well.

comment:4 Changed 12 years ago by antares190

  • Component changed from Transmission to Mac Client
  • Owner set to livings124
  • Severity changed from Normal to Major

Transmission 1.80 SnowLeopard? MacBook? (Intel2Duo).

Whatever i do the application crashes. The very only thing i can do is scrolling between the torrents in the main window (but without touching them...)

comment:5 Changed 12 years ago by 4rG

I try Transmission-9994.dmg on my MacBook?, now it works.

comment:6 Changed 12 years ago by Robby

  • Milestone changed from None Set to 1.81

comment:7 Changed 12 years ago by livings124

  • Component changed from Mac Client to Transmission

antares190: As stated above, try a nightly and report back (

comment:8 Changed 12 years ago by livings124

  • Summary changed from Transmission 1.80 (Mac) suspends at the start to Transmission 1.80 suspends at the start

comment:9 Changed 12 years ago by charles

  • Cc jch@… added

comment:10 Changed 12 years ago by charles

  • Owner changed from livings124 to charles
  • Status changed from new to assigned

Continuing the recent trend of cc'ing jch on tickets that I want reviewed by someone competent at networking -- in other words, someone who's not me.

jch: would it be possible for you to review this new DNS code -- it's pretty straightforward, but I'd appreciate the second pair of eyes on it.

The code is in And the flow is always, unconditionally doDNS() --> dns_ipv4_done_cb() --> dns_ipv6_done_cb() --> addTask(). If we're able to do the DNS lookup in a nonblocking way, we hack the resolved IP into the URL and set the HTTP request's Host header by hand. If we're not able to do that, we just pass the original URL to libcurl to see if it has better luck.

My particular concerns are

  1. Right now we go with the first IPv4 address we find, or failing that, the first IPv6 address that inet_ntop() can handle. Surely there's a better way to decide which address to use in cases where more than one is returned by the DNS.
  1. Whether or not there's a better way to do this that's beneficial for ticket #1731

Also, as an aside -- if you don't like being CCed to tickets like this, let me know and I'll stop. You're not often in irc, so mail seems like the best way of contacting you.

comment:11 Changed 12 years ago by livings124

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

comment:12 Changed 12 years ago by jch

I think that's the wrong way to go around it.

There's a major flaw with getaddrinfo -- it doesn't have a non-blocking interface. Unfortunately, replacing getaddrinfo in user code is not a good idea, since, as you have discovered, you have no chance of doing address selection correctly in user code. (And yes, I've done it -- see ).

The only reasonable way is to move all of the blocking code into a separate thread. This is the main reason why I'm submitting #2808.

comment:13 Changed 12 years ago by jch

Other than the above, I don't see anything obviously wrong in your code.

Note: See TracTickets for help on using tickets.