305541 - nsIDNSService.asyncResolve() in JavaScript causes Firefox to hang/crash

Status: RESOLVED INVALID

(Core :: Networking, defect)

Description

[Nem Mondomel]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.2; SV1; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; hu-HU; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

I'm trying to do some DNS lookups in my custom extension for Firefox, but 
unfortunately I can not do it asynchronously. If I call DNSService.resolve() 
everything goes fine (except that it's blocking for 2-3 seconds), but if I try 
to call .asyncResolve() specifying a JavaScript object as a provider for the 
IDNSListener interface, the entire browser hangs (you can quit it only by 
killing the process). 

The code in question is: 

Code: 

xxx.prototype.resolve = function(hostname) 
{ 
    const dns = Components.classes["@mozilla.org/network/dns-service;1"]. 
                 getService(Components.interfaces.nsIDNSService); 

    this.resolvehandle = dns.asyncResolve(hostname,false,this,null); 
} 

xxx.prototype.onLookupComplete = function(request, rec, status) 
{ 
  alert('Got reply'); 
} 

xxx.prototype.QueryInterface = function(aIID) 
{ 
  if ( 
      (!aIID.equals(Components.interfaces.nsISupports)) && 
      (!aIID.equals(Components.interfaces.nsIDNSListener)) 
     ) 
    throw Components.results.NS_ERROR_NO_INTERFACE; 
  return this; 
} 
 


The alert() doesn't get called at all, nor do I receive any exception (or at 
least I cannot see any in the JS console, coz FF hangs). 

When i try to use an event queue instead, like: 
Code: 

    const eventqueuesvc = Components. 
            classes["@mozilla.org/event-queue-service;1"]. 
            getService(Components.interfaces.nsIEventQueueService); 
    this.eventqueue = eventqueuesvc.createThreadEventQueue(); 
    dns.asyncResolve(hostname,0,null,this.eventqueue); 
 

almost the same thing happens, except that FF terminates abnormally with a null-
pointer exception 2-3 second after the freeze. 

Reproducible: Always

Steps to Reproduce:
1. Execute code specified in the message

Actual Results:  
Firefox hangs/crashes. (Using listener interface causes always a HANG, using 
queue causes always a CRASH.)

Expected Results:  
Execute the DNS query and the issue a callback on the listener interface, or 
place an event in the queue.

Comment 1

[Nem Mondomel]

Have now tested it with FF 1.0.6 (Mozilla/5.0 (Windows; U; Windows NT 5.2; hu-
HU; rv:1.7.10) Gecko/20050717 Firefox/1.0.6) - same things happen as with 1.0.4.

Comment 2

[:Gavin Sharp [email: [e-mail]]]

Can you try a recent trunk build?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Comment 3

[Nem Mondomel]

(In reply to comment #2)
> Can you try a recent trunk build?
> http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

My extension causes Deer Park releases to crash almost immediately right after 
startup (even before it gets a chance to execute the DNS-specific code 
described in this entry), probably due to some other bugs introduced recently 
in the Mozilla codebase. This (crash after startup) happened with previous Deer 
Park versions, too, but never with older Firefoxes (so I didn't care about it).

So, I actually can't test right now if the DNS-specific problem persists in the 
latest builds, coz Deer Park crashes before my extension issues the DNS query.

Comment 4

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

you should get the current thread's event queue and pass that
(nsIEventQueueService::getSpecialEventQueue). that should fix your problems.
Also note that the second argument to asyncResolve is an integer, not a boolean,
so passing 0 would be better...

Comment 5

[Nem Mondomel]

(In reply to comment #4)
> you should get the current thread's event queue and pass that
> (nsIEventQueueService::getSpecialEventQueue). that should fix your problems.
It didn't. I changed the 

this.eventqueue = eventqueuesvc.createMonitoredThreadEventQueue();

line to

this.eventqueue = eventqueuesvc.getSpecialEventQueue
(Components.interfaces.nsIEventQueueService.CURRENT_THREAD_EVENT_QUEUE);

but now I get an NS_ERROR_INVALID_POINTER exception in the dns.asyncResolve() 
call.

I've also tried with nsIEventQueueService.UI_THREAD_EVENT_QUEUE, but then it 
freezes exactly the same way as if I'd use the listener callback (I guess the 
latter bases on the same method internally, ie. uses the UI queue).

> Also note that the second argument to asyncResolve is an integer, not a 
boolean,
> so passing 0 would be better...
This doesn't matter (the freeze/crash happens indepentently of passing zero or 
false).

Btw. I've now managed to remove some code from my extension that caused the 
immediate crash under Deer Park releases (I still don't know what's causing the 
crash, but at least I could avoid it), and could check the DNS resolution code 
under it: it produces the same results (crach/hang) as older (1.0.x) Firefox 
versions.

Comment 6

[Nem Mondomel]

(In reply to comment #5)
> this.eventqueue = eventqueuesvc.getSpecialEventQueue
> (Components.interfaces.nsIEventQueueService.CURRENT_THREAD_EVENT_QUEUE);
> but now I get an NS_ERROR_INVALID_POINTER exception in the dns.asyncResolve() 
> call.
> I've also tried with nsIEventQueueService.UI_THREAD_EVENT_QUEUE, but then it 
> freezes exactly the same way as if I'd use the listener callback.
Sorry, I was wrong. If I use UI_THREAD_EVENT_QUEUE I get an exception just like 
with CURRENT_THREAD_EVENT_QUEUE. 

Comment 7

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

hm... the only way I can see that happen is when you pass a null listener to
asyncResolve...

oh. from your code:
    dns.asyncResolve(hostname,0,null,this.eventqueue); 

You need to specify both a listener and an event queue

Comment 8

[Nem Mondomel]

(In reply to comment #7)
> hm... the only way I can see that happen is when you pass a null listener to
> asyncResolve...
> oh. from your code:
>     dns.asyncResolve(hostname,0,null,this.eventqueue); 
> You need to specify both a listener and an event queue

That seems to solve the problem. Thanks for your help. 

However, at least the documentation should be corrected that listenerEventQ is 
NOT an optional parameter (at least it's not in current FF and DP versions, if 
ever intended to be - as the comment in nsIDNSListener.idl states).

Comment 9

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

it is optional... C++ can usually deal fine with not passing it. only JS usually
fails to deal.

Comment 10

[timeless]

if you actually manage to crash, could you crash w/ a talkback enabled build? 
i'd rather we not crash ....

Comment 11

[Nem Mondomel]

(In reply to comment #10)
> if you actually manage to crash, could you crash w/ a talkback enabled build? 
> i'd rather we not crash ....

Where can I download such a build for win32?

Comment 12

[timeless]

the normal firefox installer should install talkback if you go to custom and 
select talkback.

if you can reproduce this with a seamonkey nightly, this link should include 
talkback: http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-
trunk/seamonkey-1.0a.en-US.win32.zip

(i don't normally run firefox builds, so it's hard for me to speak for them)

Comment 13

[Nem Mondomel]

Sorry, but I cannot test my extension under Seamonkey, coz when I try to 
install it, SM complains about a missing install script (I guess he's searching 
for the infamous install.js in the .xpi, but I've only an install.rdf there).

Btw. the startup logo of Seamonkey is really great :)