289233 - chatzilla hangs when connecting to a server waiting on DNS

Status: RESOLVED FIXED

(Other Applications :: ChatZilla, defect)

Description

[Andrew Schultz]

With the fix for bug 287729, chatzilla hangs at startup waiting on (my Verizon
pathetically slow) DNS lookups.  The code calls nsIDNSService.resolve, which says:

     * called to synchronously resolve a hostname.  warning this method may
     * block the calling thread for a long period of time.  it is extremely
     * unwise to call this function on the UI thread of an application.

nsIDNSService provides asynResolve, although I imagine it isn't as easy to use.

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

hm? that patch uses nsIProtocolProxyService.resolve, not nsIDNSService.resolve...

Are you using a PAC file?

Comment 2

[Darin Fisher]

I don't see the relationship between that patch and this bug.  Do you have a PAC
URL configured in your proxy settings?  The code in that patch is calling
nsIProtocolProxyService::resolve, which will only invoke DNS if PAC is enabled.

Comment 3

[Andrew Schultz]

Attachment: stacktrace during hang

this is a stack during the hang I get

Comment 4

[Christian :Biesinger (don't email me, ping me on IRC)]

what does "call DumpJSStack()" say in the XPTC_InvokeByIndex frame? hm... that
would require a debug build...

Comment 5

[Andrew Schultz]

I have "direct connection to the internet" selected in the proxies pref panel.

Comment 6

[:Gijs (he/him)]

We're using nsIProtocolProxyService::resolve, as Darin mentioned. I'm wondering,
however, if we should do this differently. This resolve function can,
theoretically, also hang the UI (if I read the following correctly, that is:
http://lxr.mozilla.org/seamonkey/source/netwerk/base/public/nsIProtocolProxyService.idl#57)


Darin, should we do this differently? (And is it possible that this call is
indeed hanging chatzilla?

As a temporary workaround, you could try setting another DNS server, or use the
Linux equivalent of Windows' HOSTS file (I don't know if that exists, but anyway).

Comment 7

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #6)
> We're using nsIProtocolProxyService::resolve, as Darin mentioned. I'm wondering,
> however, if we should do this differently. This resolve function can,
> theoretically, also hang the UI

Yeah, but only if a PAC file is configured, which it isn't per comment 5.

> use the
> Linux equivalent of Windows' HOSTS file (I don't know if that exists, but anyway).

fwiw, windows copied that from unix. so yes, linux does have /etc/hosts ;)

Comment 8

[Andrew Schultz]

Attachment: js stack during hang

Looks like DCC is to blame, doing a lookup on my own hostname.	This happens
after I successfully connect to a server.

Comment 9

[Darin Fisher]

dcc_addhost calls the synchronous DNS resolve method.  Someone should consider
rewriting the DCC code to use asyncResolve instead to avoid hanging the UI like
this.

Comment 10

[Darin Fisher]

Hmm... actually, it looks like it only calls addHost on dns.myHostName and
"localhost" ... both of which should resolve instantly.  Perhaps your system is
not well configured.

Comment 11

[Andrew Schultz]

my PPPoE/DHCP setup does not add my own hostname/ip address to my hosts file.  I
don't think the dialer I used for modem connections did either.  Without that,
this is going to get hit.

Comment 12

[Darin Fisher]

That may be a common enough configuration to justify moving this code to use
asyncResolve in place of resolve.

Comment 13

[:Gijs (he/him)]

Removing regression keyword, as this is not a regression from the bug mentioned
in comment #0.

As mentioned to the reporter on IRC, a workaround for this stack being executed
is setting the dcc.useServerIP preference to false, which stops the client from
asking the server what its host is, and trying to process that. 

Apparently the resolving of "localhost" and dns.myHostName does work on this
system. Resolving these should happen before connecting to a server. When you
connect to a server and the dcc.useServerIP preference is 'true', the client
will issue a userhost command, and when that returns it will try to process the
returned host into an ip using the nsIDNSService.resolve method. I suppose that
it would be best making the code use asyncResolve, as darin mentioned, to stop
this from hanging the UI.

(You say ChatZilla hangs on startup. I'm supposing that you have a few networks
set to open automatically on startup? Those would have triggered the stacks
attached to this bug)

Comment 14

[James Ross]

Attachment: Use asyncResolve instead of resolve

Comment 15

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 188020 [details] [diff] [review]
Use asyncResolve instead of resolve

FWIW, this code does not handle DNS resolution failure. maybe it should.
(record is null in such a case in onLookupComplete. And status is a failure
status)

Comment 16

[James Ross]

Attachment: This time lets not break on error

DNS resolution never fails, right? ;)

Comment 17

[James Ross]

Comment on attachment 188031 [details] [diff] [review]
This time lets not break on error

Spotted a typo in the asyncResolve call.

Comment 18

[James Ross]

This bug was fixed by attachment 190316 [details] [diff] [review] of bug 299458.

Comment 19

[James Ross]

Oops, make that attachment 190304 [details] [diff] [review] of bug 299458.