122675 - socket transport doesn't cancel properly if busy resolving or connecting

Status: RESOLVED FIXED

(Core :: Networking, defect, P1)

Description

[Darin Fisher]

i discovered several problems with the socket transport / dns service when
mozilla is run on a system that cannot reach its DNS server.  the problem is
mostly XP, with a specific problem in the XP_UNIX DNS service impl.

steps to repro:

1) disconnect ethernet cable
2) load www.mozilla.org
3) status bar reads "resolving www.mozilla.org"
4) press stop
5) status bar reads "Document: done"
6) load www.mozilla.org again
7) status bar still reads "Document: done", but throbber indicates browser is busy.

what's going on?

it turns out that the first request for www.mozilla.org is not being canceled
completely.  the DNS request is still active, and the socket transport for the
first request has not fired OnStopRequest.  as a result, the first request has
not closed its cache entry.  the subsequent request gets blocked waiting for the
cache service to give it access to the cache entry for www.mozilla.org.

ok, so what if we try loading a different host subsequently?

0) restart mozilla
1) disconnect ethernet cable
2) load www.mozilla.org
3) status bar reads "resolving www.mozilla.org"
4) press stop
5) status bar reads "Document: done"
6) load www.mozillazine.org
7) status bar still reads "Document: done", but throbber indicates browser is busy.

ok, now what?

this time, the subsequent request was able to access the cache entry for
www.mozillazine.org, but it still didn't report that it was resolving
www.mozillazine.org.  turns out that socket transport thread is actually stuck
waiting to access the DNS service lock.  the problem being that the DNS service
holds its lock while calling gethostbyname, and gethostbyname blocks until it
times out.

if i modify the code to exit the lock before calling gethostbyname and then
re-enter the lock after gethostbyname returns, the problem is almost solved.  it
turns out that the first example of reloading www.mozilla.org still fails
because i still haven't solved the problem of OnStopRequest not being fired
until the DNS request times out... despite the fact that the user canceled the
request.

this points to a flaw in the socket transport.  cancel is not causing the DNS
request to be canceled.  in fact, a socket transport log reveals that we are
actually issuing a new DNS request instead of processing the cancelation.  in
fact, after reading the code, it appears that there is no code in place to
handle cancelation during the resolve and connect steps.  this can be fixed by
checking the status of mReadRequest and mWriteRequest at the top of
nsSocketTransport::Process.

patch in hand.

Comment 1

[Darin Fisher]

Attachment: v1.0 patch

Comment 2

[Darin Fisher]

gordon: can you review this patch?  thx!

Comment 3

[gordon]

Comment on attachment 67227 [details] [diff] [review]
v1.0 patch

I think this looks good. I thought about moving the unlocking of the dns
service to a different spot, but I think it best left where you have it. 
r=gordon.

Comment 4

[Scott MacGregor]

Comment on attachment 67227 [details] [diff] [review]
v1.0 patch

sr=mscott

Comment 5

[Darin Fisher]

fixed-on-trunk

Comment 6

[Mike Kaply [:mkaply]]

*** Bug 123163 has been marked as a duplicate of this bug. ***