90831 - crash when I try to fill in / submit the form on this page

Status: VERIFIED DUPLICATE of bug 68488

(Core :: XPConnect, defect)

Description

[Dave Barrowman]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.2) Gecko/20010713
Netscape6/6.1
BuildID:    20010713

The browser crashes when I try to fill in and submit the form on
http://www.attws-sf.com/content/Service_Features/Service/Digital_Benefits/Send_a_PCS_Text_Message/send_a_pcs_text_message.html
 

Reproducible: Always
Steps to Reproduce:
1. Go to
http://www.attws-sf.com/content/Service_Features/Service/Digital_Benefits/Send_a_PCS_Text_Message/send_a_pcs_text_message.html
2. Fill some values in the form
3. Submit the form.  Browser will crash.

Actual Results:  Browser crashes.

Expected Results:  Form should have been submitted.

Comment 1

[Matthias Versen [:Matti]]

confirming with win2k build 20010713..

Stack Trace :
242a3101()
XPCWrappedNative::FlatJSObjectFinalized(JSContext * 0x053d7848, JSObject * 
0x05479478) line 899
XPC_WN_NoHelper_Finalize(JSContext * 0x053d7848, JSObject * 0x05479478) line 623
js_FinalizeObject(JSContext * 0x053d7848, JSObject * 0x05479478) line 1768 + 277 
bytes
js_GC(JSContext * 0x053d7848, unsigned int 0) line 1217 + 11 bytes
js_ForceGC(JSContext * 0x053d7848) line 943 + 11 bytes
JS_GC(JSContext * 0x053d7848) line 1619 + 9 bytes
nsJSContext::GC(nsJSContext * const 0x053d77e0) line 1341 + 13 bytes
GlobalWindowImpl::SetNewDocument(GlobalWindowImpl * const 0x053d76b8, 
nsIDOMDocument * 0x05657544) line 404
DocumentViewerImpl::Init(DocumentViewerImpl * const 0x0547f810, nsIWidget * 
0x05436b84, nsIDeviceContext * 0x05445b38, const nsRect & {...}) line 970
nsDocShell::SetupNewViewer(nsDocShell * const 0x054264a0, nsIContentViewer * 
0x0547f810) line 4090 + 66 bytes
nsWebShell::SetupNewViewer(nsWebShell * const 0x054264a0, nsIContentViewer * 
0x0547f810) line 347 + 13 bytes
nsDocShell::Embed(nsDocShell * const 0x054264c4, nsIContentViewer * 0x0547f810, 
const char * 0x023ace88, nsISupports * 0x00000000) line 3545 + 23 bytes
nsWebShell::Embed(nsWebShell * const 0x054264c4, nsIContentViewer * 0x0547f810, 
const char * 0x023ace88, nsISupports * 0x00000000) line 376
nsDocShell::CreateContentViewer(nsDocShell * const 0x054264a0, const char * 
0x0012fa4c, nsIRequest * 0x054e90f8, nsIStreamListener * * 0x0012fa9c) line 3827 
+ 32 bytes
nsDSURIContentListener::DoContent(nsDSURIContentListener * const 0x05426910, 
const char * 0x0012fa4c, int 7, nsIRequest * 0x054e90f8, nsIStreamListener * * 
0x0012fa9c, int * 0x0012fa30) line 119 + 33 bytes
nsDocumentOpenInfo::DispatchContent(nsIRequest * 0x054e90f8, nsISupports * 
0x00000000) line 343 + 93 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x055168a8, 
nsIRequest * 0x054e90f8, nsISupports * 0x00000000) line 217 + 16 bytes
nsHttpChannel::ProcessNormal() line 466 + 42 bytes
nsHttpChannel::ProcessResponse() line 391 + 8 bytes
nsHttpChannel::OnStartRequest(nsHttpChannel * const 0x054e90fc, nsIRequest * 
0x056615a0, nsISupports * 0x00000000) line 2067 + 11 bytes
nsOnStartRequestEvent::HandleEvent() line 109 + 53 bytes
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x053da1a4) line 64
PL_HandleEvent(PLEvent * 0x053da1a4) line 590 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x00e97170) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x000601a4, unsigned int 49387, unsigned int 0, 
long 15298928) line 1071 + 9 bytes
USER32! 77e02e98()
USER32! 77e030e0()
USER32! 77e05824()
nsAppShellService::Run(nsAppShellService * const 0x00f83d10) line 422
main1(int 2, char * * 0x003578d8, nsISupports * 0x00000000) line 1174 + 32 bytes
main(int 2, char * * 0x003578d8) line 1478 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e87d08()

Comment 2

[Tuukka Tolvanen (sp3000)]

win98 Mozilla trunk build 2001071304: I crash with these two simple steps:
1) click or tab focus to "Message:" field
2) wait <10 seconds.
...with either "MOZILLA caused an invalid page fault in module MSVCRT.DLL at
0167:7800d32f" (TB32904311G, TB32904302E)
...or "MOZILLA caused an invalid page fault in module JSDOM.DLL at
0167:60599f3c" (TB32905426W, TB32905396G).
Crash may also occur while typing into the "Message:" field, or while submit in
progress, but never without the "Message:" field in focus. Must be that
javascript character counter they have there.

Comment 3

[Phil Schwartau]

cc'ing jband for advice: does this stack trace really implicate XPConnect,
or are the top frames here just victims? In particular, I'm wondering about
this sequence:


nsJSContext::GC(nsJSContext * const 0x053d77e0) line 1341 + 13 bytes
GlobalWindowImpl::SetNewDocument(GlobalWindowImpl * const 0x053d76b8, 
nsIDOMDocument * 0x05657544) line 404
DocumentViewerImpl::Init( etc.)


Why would GC be called from SetNewDocument? Does that seem right? 
Here is some code from SetNewDocument(): 


389    if (mContext && mJSObject) {
390 // if (mContext && mJSObject && aDocument) {
391 // not doing this unless there's a new document prevents a closed window's
392 // JS properties from going away (that's good) and causes everything,
393 // and I mean everything, to be leaked (that's bad)
394      ::JS_ClearScope((JSContext *)mContext->GetNativeContext(), mJSObject);
395 
396       mIsScopeClear = PR_TRUE;
397     }
398   }
399 }
400 
401 //XXX Should this be outside the about:blank clearscope exception?
402 mDocument = nsnull;         // Forces Release
403 }
404 
405 if (mContext && aDocument) {
406   // Add an extra ref in case we release mContext during GC.
407   nsCOMPtr<nsIScriptContext> kungFuDeathGrip = mContext;
408   kungFuDeathGrip->GC();
409 }
410 
411 mDocument = aDocument;
412 
413 if (mDocument && mContext && mIsScopeClear) {
414   mContext->InitContext(this);
415 }

Comment 4

[David Bradley]

I've been able to get it to crash, but it's not the same stack.

Basically a timer fired and the closer object it was passing was invalid.

Comment 5

[David Bradley]

Attachment: Stackdump of another crash, different from the reporters

Comment 6

[Matthias Versen [:Matti]]

Attachment: different Stack with the same build I generated the other stack.

Comment 7

[Matthias Versen [:Matti]]

I get different stacks here.
I attached the stack of crash#2 (different stack) and crash#3 has the same stack 
as crash#1 (posted at 2001-07-14 16:54)
BTW: I posted the stack and not the reporter.

Comment 8

[David Bradley]

I got that stack matti posted also. It occured the second run after my first
crash. Now I can't reproduce the crash at all.

This stack trace shows that we were jumping to no-man's land due to a invalid or
corrupted vtable. I'm starting to worry that something nasty is going on. I also
got a crash at exit after viewing this page.

Going to try a Purify run with this and see what happens.

Comment 9

[John Bandhauer]

jst says this timer bug is a dup. I'm guessing he means bug 68488. Other crash
stacks here are probably secondary effects of the core problem.

*** This bug has been marked as a duplicate of 68488 ***

Comment 10

[Phil Schwartau]

Marking Verified Duplicate -