190000 - crashes [@ PR_SetPollableEvent] (often caused by disabled loopback interface)

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect, P1)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

This looks like a regression from bug 176919 based on when it started showing up
in talkback.

PR_SetPollableEvent   12 
BBID range: 16354288 - 16412076
Min/Max Seconds since last crash: 2 - 40975
Min/Max Runtime: 2 - 40975
Crash data range: 2003-01-19 to 2003-01-20
Build ID range: 2003011804 to 2003012008
Keyword List : 
Stack Trace: 

	 PR_SetPollableEvent	[prpolevt.c  line 499]
	 nsSocketTransportService::PostEvent
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsSocketTransportService2.cpp 
line 116]
	 nsHttpConnectionMgr::PostEvent
[c:/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHttpConnectionMgr.cpp 
line 145]
	 nsHttpConnectionMgr::PruneDeadConnections
[c:/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHttpConnectionMgr.cpp 
line 184]
	 nsHttpHandler::Observe
[c:/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHttpHandler.cpp  line 1632]
	 nsTimerImpl::Fire	[c:/builds/seamonkey/mozilla/xpcom/threads/nsTimerImpl.cpp 
line 391]
	 handleTimerEvent	[c:/builds/seamonkey/mozilla/xpcom/threads/nsTimerImpl.cpp 
line 449]
	 PL_HandleEvent	[c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c  line 664]
	 PL_ProcessPendingEvents	[c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c 
line 597]
	 nsEventQueueImpl::ProcessPendingEvents
[c:/builds/seamonkey/mozilla/xpcom/threads/nsEventQueue.cpp  line 391]
 
 	Source File : prpolevt.c line : 499
     (16412076)	Comments: Man  it's sux... :(
     (16405223)	Comments: After download of nighly closed mozilla  and unzipped
nightly over old. When I started mozilla  ZoneAlarm asked me TWO times for
Serverrights  and I allowed  then regognized that TWICE is unusual  so denied
next question for Client Connect to Internet 
     (16405223)	Comments:  selected profile  and closed mozilla  to check
installation and firewall  before going online. At closing mozilla crashed.
     (16388785)	Comments: Crashed on first initialization after download.
     (16375020)	Comments: all i did was close the SOB.  
     (16361638)	Comments: this sucks
     (16360147)	Comments: started freshly installed (Zip-version) mozilla  had
to answer ZoneAlarms question for Server-Rights TWICE  (Yes)  and then  denied
Client-Rights  to think look about Server-Rights again.  ProfileMnager Came up 
and I aborted Mozilla.  Talkback came up.

Comment 1

[Darin Fisher]

oh joy!

Comment 2

[Darin Fisher]

different stack trace, indicates user was loading PAC file when crash occured:

    	 PR_SetPollableEvent   	[prpolevt.c, line 499]
    	nsSocketTransportService::PostEvent 
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsSocketTransportService2.cpp,
line 116]
    	nsHttpConnectionMgr::PostEvent 
[c:/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHttpConnectionMgr.cpp,
line 145]
    	nsHttpConnectionMgr::AddTransaction 
[c:/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHttpConnectionMgr.cpp,
line 157]
    	nsHttpChannel::Connect 
[c:/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp, line 320]
    	nsHttpChannel::AsyncOpen 
[c:/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHttpChannel.cpp, line 2422]
    	XPTC_InvokeByIndex 
[c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp,
line 102]
    	XPCWrappedNative::CallMethod 
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2025]
    	XPC_WN_CallMethod 
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1293]
    	js_Invoke 	[c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 841]
    	js_Interpret 	[c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 2804]
    	js_Invoke 	[c:/builds/seamonkey/mozilla/js/src/jsinterp.c, line 857]
    	nsXPCWrappedJSClass::CallMethod 
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1199]
    	nsXPCWrappedJS::CallMethod 
[c:/builds/seamonkey/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 429]
    	PrepareAndDispatch 
[c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp,
line 117]
    	SharedStub 
[c:/builds/seamonkey/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp,
line 139]
    	nsProtocolProxyService::HandlePACLoadEvent 
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsProtocolProxyService.cpp, line 280]
    	PL_HandleEvent 	[c:/builds/seamonkey/mozilla/xpcom/threads/plevent.c, line 664]
    	PL_ProcessPendingEvents 

Comment 3

[Mike Kaply [:mkaply]]

We have at least three OS/2 people that are seeing this, other people are
working fine.

We are trying to figure out what they have in common.

Comment 4

[Mike Kaply [:mkaply]]

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

Comment 5

[Mike Kaply [:mkaply]]

Comment from one of the other guys that sees this:

The only obvious thing I see in common so far, that we all seem to use
K6-2(+)/III CPU's

K6-2+/450, Warp4 FP15, Krnl14.093c, Mozilla 1.3b Build 20030111, TCP/IP 4.1 

Anyone else seeing this problem using AMD?

Comment 6

[Mike Kaply [:mkaply]]

I had people that were getting this do all:5 logging on their release build.

The last line in the log is:

0[3450c8]: nsHttpHandler::Observe [topic="timer-callback")]

Unfortunately there are no Socket Tranport calls so I believe the crash caused
the log not to finish.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

async fallout. This should be resolved for 1.3beta, one way or the other.

Comment 8

[Jan Carpenter]

Adding qawanted to keywords.

Comment 9

[Darin Fisher]

interesting that there aren't any reports of this crash on linux or mac.  the
windows implementation of the pollable event uses a socket pair.  i suspect OS/2
probably uses the same impl.  that must be significant.

Comment 10

[Darin Fisher]

here's the "timer" crash that mkaply was referring to:

PR_SetPollableEvent [prpolevt.c, line 499]
nsSocketTransportService::PostEvent
[c:/builds/seamonkey/mozilla/netwerk/base/src/nsSocketTransportService2.cpp,
line 117]
nsHttpConnectionMgr::PostEvent
[c:/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHttpConnectionMgr.cpp,
line 145]
nsHttpConnectionMgr::PruneDeadConnections
[c:/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHttpConnectionMgr.cpp,
line 184]
nsHttpHandler::Observe
[c:/builds/seamonkey/mozilla/netwerk/protocol/http/src/nsHttpHandler.cpp, line 1632]
nsTimerImpl::Fire [c:/builds/seamonkey/mozilla/xpcom/threads/nsTimerImpl.cpp,
line 391]
nsTimerManager::FireNextIdleTimer
[c:/builds/seamonkey/mozilla/xpcom/threads/nsTimerImpl.cpp, line 616]
nsAppShell::Run [c:/builds/seamonkey/mozilla/widget/src/windows/nsAppShell.cpp,
line 176]
nsAppShellService::Run
[c:/builds/seamonkey/mozilla/xpfe/appshell/src/nsAppShellService.cpp, line 480]
main1 [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1289]
main [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1639]
WinMain [c:/builds/seamonkey/mozilla/xpfe/bootstrap/nsAppRunner.cpp, line 1660]
WinMainCRTStartup()
KERNEL32.DLL + 0x1b9e4 (0xbff7b9e4)
KERNEL32.DLL + 0x1b896 (0xbff7b896)
KERNEL32.DLL + 0x1a24f (0xbff7a24f)
0x22020100 

the comment mentions quicklaunch.  the socket transport is started and stopped
during quick launch.  also, i noticed that PR_SetPollableEvent is attempting to
dereference a null pointer.  so, it would seem that the socket transport's
mThreadEvent is somehow uninitialized.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Don't take not showing up on other platforms too seriously.  Linux talkback was
only recently fixed, and I've barely seen Mac talkback reports at all.

Comment 12

[Darin Fisher]

dbaron: ok.. makes sense.

Comment 13

[Jay Patel [:jay]]

A more recent comment also mentions ZoneAlarm...I wonder if that software isn't
playing nicely with Mozilla:

16689373 OS: Windows 98 4.10 build 67766222    Comments: ZoneAlarm + Mozilla 1.
had deleted Mozilla from ZoneAlarm ZA config page open 2. started Mozilla
loading stopped when ZA asked for Server and client rights 3. I denied to set
rights directly in ZA config 4. Mozilla continued to load and I    Comments: set
rights in ZA config: allow local&remote connect local server disallow remote
server 5. Mozilla crashed while I was doing 

Comment 14

[David G King]

Re Comment #13, I'm not ZoneAlarm is a direct cause (assuming one is using v3.5
of ZA).

However, the way the user used ZoneAlarm, that is, load Mozilla with ZA having
no knowledge of what Mozilla can/can't do, and then adjust ZA would probably be
an issue with any software firewall.

For the record, I use ZoneAlarm all the time on WinXP with nightly builds with
little problem.

Comment 15

[Hermann Schwab]

re: comment #13
I produced this talkback in a very unusual situation:
I denied server rights when asked for it, and fractions of a second set
different settings in ZA´s configurtion page. BTW, it is an older version, 2.6.88
So in real life this won´t happen, because people don´t have ZA´s configuration
window open, when they are asked by mozillas very first start, and even then
they don´t make this controversial decision in such a short time interval.

I only sent that report because maybe it could shed light on a bug,
but the circumstances of this crash are completely constructed, not real life
application. Are DocWatson Logfiles helpful?

My normal way at 1st start of a nightly:
ZA asks for Server rights, and I allow,
ZA asks if client is allowed to connect to the internet, and I allow.
I then open the ZA-config-page, and disallow global server rights.

Comment 16

[Darin Fisher]

so, the problem is that we just need to null check mThreadEvent because
zone-alarm is probably denying mozilla the ability to open the loopback socket
pair!  of course... that's got to be the problem!!

Comment 17

[Darin Fisher]

Attachment: v1 patch

ok, this null check should have always been present.  at least now since we
know the reason for the failure we can add a more informative error message
(NS_ERROR_OFFLINE).  eventually it would probably be good to actually detect
this error and set the state of necko to be offline, but that can wait ;-)

Comment 18

[David G King]

ZA itself may be a misleading path, although denying local loopback at startup
could give Mozilla a hard time. Also, at least with v3.5, ZA doesn't ask for
Server rights for Mozilla.

Mind you, a NULL check on mThreadEvent couldn't hurt....(hmmm, midair collision
and I see you are doing that anyway).

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 113153 [details] [diff] [review]
v1 patch

Noting approval1.3b+ (assuming you get reviews).

Comment 20

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 113153 [details] [diff] [review]
v1 patch

sr=bzbarsky, but please investigate whether NSPR reports a useful error here
that you could use....

Comment 21

[Darin Fisher]

fixed-on-trunk

Comment 22

[Max Alekseyev]

Since bug 190033 is dupped to this one...

Now Mozilla starts fine BUT...
if loopback interface is broken (say, ping 127.0.0.1 doesn't work) then Mozilla
constantly reports "http is not a registered protocol" and refuses to connect
any site.

I see this behavior on OS/2 builds starting 01/31 and including the latest
2003020212 one.

Comment 23

[Andreas Kunz]

There seem to be at least no Win crashes since this was fixed...

Comment 24

[Mike Kaply [:mkaply]]

I've opened

http://bugzilla.mozilla.org/show_bug.cgi?id=191739

For the new bug

Comment 25

[benc]

VERIFIED/fixed per #23.