Closed Bug 48344 Opened 24 years ago Closed 24 years ago

Crash after going offline and trying to access a site

Categories

(Core :: Networking, defect, P3)

x86
Windows 98
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: gagan)

Details

(Keywords: crash, regression, Whiteboard: [nsbeta3+])

Build ID: 2000080908

Steps to Reproduce:
(1) Go offline
(2) Try to access a site (by any method...URL bar, link, etc)

Mozilla freezes at first, then crashes in XPCOM.DLL

Perhaps related to bug 41433, but I doubt it.
got stack?
Whiteboard: [nsbeta3+]
stack trace coming when the talkback server starts working.

note that in today's builds it seems to be crashing in kernel32.dll, whereas it 
was in xpcom.dll in yesterday's builds (prob. doesn't matter).
Actually, the GPF switches between XPCOM.DLL and KERNEL32.DLL

Stack trace:

  KERNEL32.DLL + 0xb9a9 (0xbff7b9a9)
MSVCRT.DLL + 0xcc74 (0x7800cc74)
MSVCRT.DLL + 0x12d9 (0x780012d9)

JS_HashTableAdd  [d:\builds\seamonkey\mozilla\js\src\jshash.c, line 273]
   
js_AddRoot [d:\builds\seamonkey\mozilla\js\src\jsgc.c, line 175]
   
JS_AddNamedRoot  [d:\builds\seamonkey\mozilla\js\src\jsapi.c, line 1100]
   
nsXPCWrappedNative::AddRef  
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, 
line 58]
   
nsXPCWrappedNative::QueryInterface  
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednative.cpp, 
line 47]
   
nsQueryInterface::operator() 
[d:\builds\seamonkey\mozilla\xpcom\base\nsCOMPtr.cpp, line 37]
   
nsCOMPtr_base::assign_from_helper  
[d:\builds\seamonkey\mozilla\xpcom\base\nsCOMPtr.cpp, line 66]
   
GetScopeOfObject  
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativescope.cpp, 
line 112]
   
nsXPCWrappedNativeScope::FindInJSObjectScope 
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativescope.cpp, 
line 138]
   
XPCConvert::NativeInterface2JSObject  
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcconvert.cpp, line 795]
   
XPCConvert::NativeData2JS 
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcconvert.cpp, line 384]
   
nsXPCWrappedNativeClass::CallWrappedMethod 
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativeclass.cpp, 
line 1009]
   
WrappedNative_GetProperty  
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappednativejsops.cpp, 
line 274]
   
js_Interpret  [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 2376]
   
js_Invoke  [d:\builds\seamonkey\mozilla\js\src\jsinterp.c, line 733]
   
nsXPCWrappedJSClass::CallMethod  
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjsclass.cpp, 
line 743]
   
nsXPCWrappedJS::CallMethod  
[d:\builds\seamonkey\mozilla\js\src\xpconnect\src\xpcwrappedjs.cpp, line 
319]
   
PrepareAndDispatch  
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp, 
line 102]
   
SharedStub  
[d:\builds\seamonkey\mozilla\xpcom\reflect\xptcall\src\md\win32\xptcstubs.cpp, 
line 125]

looks like brendan's area, cc'ing him
Someone try purify, see if memory is being trashed.  Cc'ing jband, cuz there is
xpconnect love to share.

/be
Without having tried purify yet, my instinct is a memory problem/leak, because 
of the freeze that comes before the crash.
This is network stuff.

I ran in MSVC and the error is a stack overflow.

The top of the stack on overflow is in the JS/xpconnect stuff. MSVC doesn't know 
how to show a stack back past the 'SharedStub' in xptcall stuff. But when I 
'step out' and then step some to get past that I see a stack like:

SharedStub() line 130
nsDocLoaderImpl::FireOnStateChange(nsIWebProgress * 0x03344ea4, nsIRequest * 
0x03740490, int 65537, unsigned int 0) line 1253
nsDocLoaderImpl::doStartURLLoad(nsIChannel * 0x03740490) line 666
nsDocLoaderImpl::OnStartRequest(nsDocLoaderImpl * const 0x03344e94, nsIChannel * 
0x03740490, nsISupports * 0x00000000) line 488
nsLoadGroup::AddChannel(nsLoadGroup * const 0x03344e30, nsIChannel * 0x03740490, 
nsISupports * 0x00000000) line 460 + 31 bytes
nsHTTPChannel::Open(int 0) line 1381
nsHTTPChannel::GetResponseHeader(nsHTTPChannel * const 0x03740490, nsIAtom * 
0x013e4670, char * * 0x000345a8) line 688
nsHTTPChannel::ResponseCompleted(nsIStreamListener * 0x03740e10, unsigned int 
2152398864, const unsigned short * 0x00000000) line 1774
nsHTTPChannel::Open(int 0) line 1521
nsHTTPChannel::GetResponseHeader(nsHTTPChannel * const 0x03740490, nsIAtom * 
0x013e4670, char * * 0x000347a4) line 688
nsHTTPChannel::ResponseCompleted(nsIStreamListener * 0x03740e10, unsigned int 
2152398864, const unsigned short * 0x00000000) line 1774
nsHTTPChannel::Open(int 0) line 1521
nsHTTPChannel::GetResponseHeader(nsHTTPChannel * const 0x03740490, nsIAtom * 
0x013e4670, char * * 0x000349a0) line 688
nsHTTPChannel::ResponseCompleted(nsIStreamListener * 0x03740e10, unsigned int 
2152398864, const unsigned short * 0x00000000) line 1774

... it repeats the three frame on down.
well, seems fixed in the latest builds. not gonna argue...
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
verified:
Win98 2000082308
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.