Closed Bug 233426 Opened 21 years ago Closed 8 years ago

problems after a DNS failure when you've got an alternative dialer

Categories

(Core :: Networking, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: sspitzer, Unassigned)

Details

problems after a DNS failure when you've got an alternative dialer.

note, this might already be fixed after some recent change from darin on the trunk.

but I want to start a bug anyways, since it will affect the mozilla 1.4.x branch
(and Netscape 7.1)

here's what happens:

0)  I've got an alternative dialer installed, as well as having DSL.  (my
alternative dialer is the AOL 9.x client)
1)  start up mozilla firebird (I'm running 0.6.1, but I'll try again on the
trunk once I narrow it down
2)  go to something like http://www.sethisloser.com (which doesn't exist, yet)
3)  after about 5 seconds, when the dns times out, my AOL 9.x client starts up,
and I cancel it
4)  then, it appears no more firebird DNS request will succeed, but I don't get
the alert about them failing, and AOL 9.x doesn't start up either
5)  if I try to exit Mozilla Firebird, it doesn't really exit and the process
has to be killed.
6)  once I kill it, it seems to work fine.

I'll try to narrow it down, and see where it is hung.

I think this is what mdunn was seeing
Take a look at this document:
http://www.mozilla.org/quality/networking/docs/autodial.html

And also, see if the problem goes away w/ a non-AOL dialer (see bug 166134).
ben, thanks for the info.

maybe I just need to turn it off since my AOL dialer isn't behaving nice.

darin and I chatted tonight, and I've got a stack.

NTDLL! 77f8915e()
KERNEL32! 7c59a0b8()
RASDLG! 7587c677()
RASDLG! 7587beab()
nsRASAutodial::DialDefault(const char * 0x0bd0ab70) line 318 + 21 bytes
nsNativeConnectionHelper::OnConnectionFailed(const char * 0x0bd0ab70) line 52 + 
15 bytes
nsSocketTransport::RecoverFromError() line 1159 + 28 bytes
nsSocketTransport::OnSocketDetached(PRFileDesc * 0x00000000) line 1441 + 13 
bytes
nsSocketTransport::OnSocketEvent(unsigned int 0x00000001, unsigned int 
0x804b001e, nsISupports * 0x00000000) line 1359
nsSocketEvent::HandleEvent(PLEvent * 0x0bc49340) line 97
PL_HandleEvent(PLEvent * 0x0bc49340) line 671 + 10 bytes
nsSocketTransportService::ServiceEventQ() line 350 + 9 bytes
nsSocketTransportService::Run(nsSocketTransportService * const 0x00f4eb68) line 
559 + 11 bytes
nsThread::Main(void * 0x00f4f3a8) line 118 + 26 bytes
_PR_NativeRunThread(void * 0x00f4f4a8) line 433 + 13 bytes
pr_root(void * 0x00f4f4a8) line 113 + 13 bytes
_threadstartex(void * 0x00f4f730) line 212 + 13 bytes
KERNEL32! 7c57b382()
something darin suggested:

perhaps we can fix my problem by fixing nsRASAutodial::ShouldDialOnNetworkError
() to return false if the reason we are attempting to dial is a  DNS lookup 
failure.
Seth, this auto-dial stuff was checked in for something like Netscape 6.02, then
left on by default in mozilla, and off by default in Netscape.

There are a variety of bugs filed against this feature that I never got around
to fully analyzing.

I've read the documentation a couple times, but the overall behavior has never
sat well with me, plus I don't have a PC with a working modem, so I cannot do a
lot of the usual poking and testing that I usually do.

Can you turn this pref off, and tell me how the behavior changes?

I'm also wondering if the crash is our fault, or inside the AOL dialer.
ben, there is no crash.  

darin helped me determine that what happens is the dialer never comes back, and
so the socket transport thread will not be able to do handle any more requests.

fwiw, I see've seen this in firebird, too.

NTDLL! 77f8915e()
KERNEL32! 7c59a0b8()
RASDLG! 7587c677()
RASDLG! 7587beab()
MOZILLAFIREBIRD! 004946dc()
MOZILLAFIREBIRD! 0048bb5e()
MOZILLAFIREBIRD! 00477190()
MOZILLAFIREBIRD! 0047769b()
00ec8160()
Assignee: darin → nobody
QA Contact: benc → networking
no more investment in dialer
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.