69968 - Crash rendering this URL

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[Claude Gohier]

Mozilla build 2001022209 crashes while rendering
https://directnat.bnc.ca/gpfr.asp 

on windows 2000.

Comment 1

[Claude Gohier]

Attachment: Dr. Watson log of the crash

Comment 2

[ivo]

Crash: Mozilla, Win98SE, ID:2001022105


MOZILLA caused an invalid page fault in
module GKCONTENT.DLL at 0167:014b8d0e.
Registers:
EAX=0068eea4 CS=0167 EIP=014b8d0e EFLGS=00010202
EBX=01bd1134 SS=016f ESP=0068ede0 EBP=0068edf0
ECX=00000000 DS=016f ESI=0068eea4 FS=2267
EDX=0068eda8 ES=016f EDI=01bd1138 GS=0000
Bytes at CS:EIP:
ff 51 38 eb 0a 33 c0 39 47 0c 0f 94 c0 89 06 33 
Stack dump:
0068eea4 0068eea4 00000000 80000000 0068eea8 60bae554 01bd1138 0068eea4 01bc29d0
0068f040 01803460 006b6c8c 0068ee58 00000000 006b6c8c 01598600 


At first try there was a PSM crash after this, but additional testing did not
reveal it anymore.

Comment 3

[timeless]

perhaps top.window.frames[4].location.href ? we need a reduced testcase

i'm going to place immediate blame on this code [no pointer validity checks]:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/base/src/nsTextFrag
ment.cpp&rev=1.9&mark=142#128

but it is only a symptom of
0012EFE4 60B9E590 109EE270 0012F098 0FB879D0 0012F234 
gkcontent!nsTextFragment::CopyTo 
0012F09C 60B338AB 0E86B058 0F924F58 109EE270 0012F234 
jsdom!NS_NewScriptHTMLInputElement 
0012F0D4 60B2BBC1 0000000D 0F924F58 016DB168 0012F234 js3250!js_FindProperty 
0012F23C 60B2794C 0E86B058 0012F2C8 00000001 0012F2FC js3250!js_Invoke 
0012F2DC 60B27BCF 00000001 00000001 00000002 80000000 js3250!js_Invoke 
0012F35C 60B14579 00000000 0E873090 0F924FA0 00000000 js3250!js_Invoke 
0012F380 60B6427A 0E86B058 0E873090 0F924FA0 00000001 
js3250!JS_CallFunctionValue 
0012F3C8 60B64455 00AD94D8 0E873090 0F924FA0 00000001 jsdom!NS_DOMTagToEnum 
0012F4A8 60271504 0FE6C00C 0012F73C 0E90B6C0 00000007 jsdom!NS_DOMTagToEnum 

Comment 4

[Dave]

also crashes today's Linux build.

Comment 5

[Claude Gohier]

Mozilla was not crashing there a few weeks ago. Then my company installed a
firewall and I coudn't go there anymore because of bug 31174. 

Now that this bug is fixed, I can again load the page, but it crashes...
I don't know if it's a mozilla regression, or if they changed the code of the page.

Comment 6

[Fabian Guisset]

Confirmed. Marking NEW. This worked in 0.8 (I just tried). I get the crash in
build 2001022200. Going to investigate.

Comment 7

[Stephen Walker]

Console output from a 2/24 debug build on win2k:

###!!! ASSERTION: Cannot yet handle simultaneously active requests for the same
URL using different caches: 'cache == cachedData->mCache', file c:\mozilla\moz_s
rc_debug\mozilla\netwerk\cache\mgr\nsCacheManager.cpp, line 311
###!!! Break: at file c:\mozilla\moz_src_debug\mozilla\netwerk\cache\mgr\nsCache
Manager.cpp, line 311

stack trace:

NTDLL! 77f9eea9()
nsDebug::Assertion(const char * 0x018302d0, const char * 0x018302b0, const char 
* 0x01830268, int 311) line 254 + 13 bytes
nsCacheManager::GetCachedNetData(nsCacheManager * const 0x02ff5840, const char 
* 0x03e20df8, const char * 0x00000000, unsigned int 0, unsigned int 2, 
nsICachedNetData * * 0x03e21570) line 311 + 37 bytes
nsHTTPChannel::CheckCache() line 880 + 91 bytes
nsHTTPChannel::Begin(int 0) line 1351
nsHTTPChannel::AsyncOpen(nsHTTPChannel * const 0x03e214f0, nsIStreamListener * 
0x03dbf540, nsISupports * 0x00000000) line 330
nsHTTPChannel::Authenticate(const char * 0x03e233a0, int 0) line 2179 + 45 bytes
nsHTTPChannel::ProcessAuthentication(int 401) line 2551 + 31 bytes
nsHTTPChannel::ProcessStatusCode() line 2371 + 15 bytes
nsHTTPChannel::FinishedResponseHeaders() line 2221 + 8 bytes
nsHTTPServerListener::FinishedResponseHeaders() line 1012 + 11 bytes
nsHTTPServerListener::OnDataAvailable(nsHTTPServerListener * const 0x03e30c28, 
nsIRequest * 0x03e144b8, nsISupports * 0x03e0a160, nsIInputStream * 0x03dc0340, 
unsigned int 0, unsigned int 616) line 411 + 8 bytes
nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x03dbc428) 
line 160 + 70 bytes
nsStreamObserverEvent::HandlePLEvent(PLEvent * 0x03dbc42c) line 78
PL_HandleEvent(PLEvent * 0x03dbc42c) line 576 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x033204a8) line 509 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x0042038a, unsigned int 49475, unsigned int 0, 
long 53609640) line 1054 + 9 bytes
USER32! 77e148dc()
USER32! 77e14aa7()
USER32! 77e266fd()
nsXULWindow::ShowModal(nsXULWindow * const 0x034ebe00) line 249
nsWebShellWindow::ShowModal(nsWebShellWindow * const 0x034ebe00) line 1088
nsContentTreeOwner::ShowModal(nsContentTreeOwner * const 0x03e3d238) line 187
GlobalWindowImpl::OpenInternal(GlobalWindowImpl * const 0x00c9ef20, JSContext * 
0x00d84ee0, long * 0x033f5028, unsigned int 3, int 0, nsIDOMWindowInternal * * 
0x0012fa34) line 3242
GlobalWindowImpl::Open(GlobalWindowImpl * const 0x00c9ef24, JSContext * 
0x00d84ee0, long * 0x033f5028, unsigned int 3, nsIDOMWindowInternal * * 
0x0012fa34) line 2073
nsPSMUIHandlerImpl::DisplayURI(nsPSMUIHandlerImpl * const 0x03060378, int 520, 
int 350, int 1, const char * 0x034a8228, nsIDOMWindow * 0x00000000) line 129
XPTC_InvokeByIndex(nsISupports * 0x03060378, unsigned int 3, unsigned int 5, 
nsXPTCVariant * 0x0328d5c0) line 139
EventHandler(PLEvent * 0x033f94e8) line 510 + 41 bytes
PL_HandleEvent(PLEvent * 0x033f94e8) line 576 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00b56690) line 509 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x005b0318, unsigned int 49475, unsigned int 0, 
long 11888272) line 1054 + 9 bytes
USER32! 77e148dc()
USER32! 77e14aa7()
USER32! 77e266fd()
nsAppShellService::Run(nsAppShellService * const 0x00b91708) line 408
main1(int 2, char * * 0x004b77a0, nsISupports * 0x00000000) line 978 + 32 bytes
main(int 2, char * * 0x004b77a0) line 1270 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e992a6()

cc'ing dougt

Comment 8

[Doug Turner (:dougt)]

HTTP Cache fun.  Lets cc' darin and neeti

Comment 9

[Darin Fisher]

How does that last stack trace (with the debug assertion) correspond to the
crash?  That assertion should be coupled with a failure return value, and HTTP
normally handles this error by skipping the cache.  Is this not happening?
Are we crashing at the point of assertion?

Comment 10

[Claude Gohier]

It no longer crashes with build 2001030804...

Comment 11

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Using the 2001030804 build on NT the page does not finish loading for me. When I
quit the application, it left a hidden mozilla process running so I couldn't
launch Mozilla until I killed the process from the task manager.

Comment 12

[Alexander Opitz]

worksforme in Build 2001052020 on Win95

--> Only a NT/2000 Bug?

The site makes a form redirect to the next page who is in SSL, but mozilla
doesn't show the secure state in the key symbol (modern design).

Comment 13

[Matthias Versen [:Matti]]

wfm with win2k build 20010518.. (CVS debug)

Comment 14

[Johnny Stenback (:jst)]

Marking WORKSFORME based on above comments and my own testing, please reopen if
you're still seeing this crash.