170001 - N700, M12A topcrash [@ DummyParserRequest::GetURI]

Status: VERIFIED FIXED

(Core :: DOM: Events, defect)

Description

[Jan Carpenter]

This stack signature is a topcrasher for N700, M12A

From N700:

Crash data range: 2002-09-14 to 2002-09-19
Build ID range: 2002082307 to 2002082307
Keyword List : mail(5), 

Stack Trace: 

	 DummyParserRequest::GetURI()
	 nsSecureBrowserUIImpl::OnStateChange()
	 nsDocLoaderImpl::FireOnStateChange()
	 nsDocLoaderImpl::doStopURLLoad()
	 nsDocLoaderImpl::OnStopRequest()
	 nsLoadGroup::RemoveRequest()
	 nsLoadGroup::Cancel()
	 nsDocLoaderImpl::Stop()
	 nsURILoader::Stop()
	 nsDocShell::Stop()
	 nsDocShell::InternalLoad()
	 nsDocShell::LoadURI()
	 nsDocShell::LoadURI()
	 XPTC_InvokeByIndex()
	 XPCWrappedNative::CallMethod()
	 XPC_WN_CallMethod()
	 js_Invoke()
	 js_Interpret()
	 js_Invoke()
	 js_Interpret()
	 js_Invoke()
	 fun_apply()
	 js_Invoke()
	 js_Interpret()
	 js_Invoke()
	 js_InternalInvoke()
	 JS_CallFunctionValue()
	 nsJSContext::CallEventHandler()
	 nsJSEventListener::HandleEvent()
	 nsXBLPrototypeHandler::ExecuteHandler()
	 nsXBLKeyHandler::KeyPress()
	 nsEventListenerManager::HandleEvent()
	 nsXULElement::HandleDOMEvent()
	 nsXULElement::HandleDOMEvent()
	 nsXULElement::HandleDOMEvent()
	 nsGenericElement::HandleDOMEvent()
	 nsHTMLInputElement::HandleDOMEvent()
	 PresShell::HandleEventInternal()
	 PresShell::HandleEvent()
	 nsViewManager::HandleEvent()
	 nsView::HandleEvent()
	 nsViewManager::DispatchEvent()
	 HandleEvent()
	 nsWidget::DispatchEvent()
	 nsWidget::DispatchWindowEvent()
	 nsWidget::OnKey()
	 handle_key_press_event()
	 dispatch_superwin_event()
	 handle_gdk_event()
	 libgdk-1.2.so.0 + 0x174db (0x403444db)
	 libglib-1.2.so.0 + 0x10186 (0x40374186)
	 libglib-1.2.so.0 + 0x10751 (0x40374751)
	 libglib-1.2.so.0 + 0x108f1 (0x403748f1)
	 libgtk-1.2.so.0 + 0x8c5b9 (0x402985b9)
	 nsAppShell::Run()
	 nsAppShellService::Run()
	 netscape-bin + 0x90b9 (0x080510b9)
	 netscape-bin + 0x98a7 (0x080518a7)
	 libc.so.6 + 0x189cb (0x404759cb)

COMMENTS/URLs:

     (11182811)	URL: dftuz.unizar.es
     (11182811)	Comments: sending a printing request to a LaserPrinter using an
html form. Not  the first time it breaks down  but first time using N7.0
     (11099207)	URL: https://www.myssed.com/webmail (logged in)
     (11099207)	Comments: Same deal...SSL on webmail crashes this bitch.
     (11095239)	URL: https://www.myssed.com/webmail (logged in)
     (11095239)	Comments: Logged into my webmail account  trying to delete some
files  apparently some SSL message from the server crashed netscape?
     (11075174)	Comments: Selected a form element for file browsing.
     (11045812)	URL: www.wrexhamafc.co.uk
     (11045812)	Comments: registering for a message board
     (11037292)	URL: http://webmail.forethought.net
     (11037292)	Comments: I was attempting to delete a message in webmail.
     (11035215)	URL: www.imagestation.com
     (11035215)	Comments: trying to send an invite to an album
     (11030351)	URL: mail.yahoo.com
     (11030351)	Comments: Deleting email when in Yahoo! Mail.
     (11023642)	Comments: posting a form
     (11005354)	URL: www.geocities.com
     (11003672)	URL: www.trw.com
     (11003672)	Comments: i used the back button and this thing came up
     (10948729)	Comments: checking my mail

Comment 1

[greer]

Darin, is this your bug, perhaps? I don't think it is Form Submission. And it's
getting a lot of business in N700, with scattered crashes in N1.2a, also.

Comment 2

[Darin Fisher]

no, doesn't look like it.

Comment 3

[Alexandru Savulov]

is this really linux only? hmmm, usually form submission crashers are
cross-platform.

Comment 4

[Jay Patel [:jay]]

Not sure if this problem is Linux only or not, but the stack signature reported
is only showing up for Linux builds.  I tried to dig through comment reports to
see if there were comparable crashes on other platforms, but didn't find much.  

Are we sure this is a form submission bug?  A few of the comments mention
crashing while deleting an SSL message from a yahoo mail account.

Comment 5

[Radha on family leave (not reading bugmail)]

From the stack trace it looks like the following is happening:

1) A key press event triggers a event handler set for it.
2) This event handler  tries to load a page.
3) When the new page begins to load, docshell first cancels any current load.

It is step 3 that the crash is happening, probably because there is still
something  pending  from hte previous load...

Comment 6

[Alexandru Savulov]

well, there is nothing in the attached stack that leads to form submission (none
of the methods listed there are part of the form submission code). i'm tempted
to say is not form submission.

Comment 7

[Brian Ryner (not reading)]

I'm getting this only on optimized builds on Linux.  I can reproduce this
reliably on the trunk:

- Do a bugzilla query
- Click "Edit several bugs at once" at the bottom of the list (I think someone
has to enable this for your bugzilla account if you don't see it there)
- Check a couple of bugs
- Change the target milestone
- Click Commit.

It's crashing here:

#0  DummyParserRequest::GetURI(nsIURI**) (this=0x448fad00, aURI=0xbfffebb0)
    at nsHTMLContentSink.cpp:693
693         NS_ADDREF(*aURI);

because *aURI (and gURI, which was just assigned to it) are null.  gURI is set
whenever SetOriginalURI or SetURI is called on the DummyParserRequest.

Comment 8

[Brian Ryner (not reading)]

There seems to be some weird corruption of gRefCnt happening which is causing a
new gURI not to be created.  Inspecting gRefCnt at the time of the crash gives
1085710505.

Comment 9

[Brian Ryner (not reading)]

I have a fix.

Basically, what was happening is that the arena used for nsDOMEvents (which is
exactly the size of 1 nsDOMEvent) was inadvertently being used for
nsDOMMutationEvents, which are 4 bytes larger.  The storage space for the arena
happens to come just before the storage for DummyParserRequest::gRefCnt.  So,
the nsDOMMutationEvent would write into its last 4 bytes, which actually
overwrote gRefCnt, causing gURI to not be recreated when a new
DummyLayoutRequest was created.

Comment 10

[Brian Ryner (not reading)]

Attachment: patch

only use the nsDOMEvent arena if we're allocating a number of bytes less than
or equal to the size of the arena.

Comment 11

[jag (Peter Annema)]

Comment on attachment 104482 [details] [diff] [review]
patch

sr=jag

Comment 12

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

Comment on attachment 104482 [details] [diff] [review]
patch

r=dbaron

Comment 13

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

Comment on attachment 104482 [details] [diff] [review]
patch

a=roc+moz for trunk

Comment 14

[Brian Ryner (not reading)]

checked in.

Comment 15

[Michael Buckland]

jag suggested via email.  nominating & will discuss at bBird team meeting today.

Comment 16

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 104482 [details] [diff] [review]
patch

a=[e-mail] for 1.0 branch; change mozilla1.0.2+ to fixed1.0.2 when
checked in

Comment 17

[Michael Buckland]

Discussed in team meeting.  All reported crashes are linux.  We just can't take
this and make our candidate build date.  Minusing

Comment 18

[Randell Jesup [:jesup] (needinfo me)]

While the stack trace may only list Linux, it's possible that other platforms
may crash with different traces (due to different allocators), perhaps many
operations later.  (i.e. it may leave a timebomb that code will trip over much
later, plus what gets trashed may be highly dependant on timing a order of
operations.)

I think you're foolish not to take a safe fix like this, but that's just my
opinion.  When we (Worldgate) update to 1.0.2 soon I'll need to add this patch
in myself to our tree if it's not in the branch; adding [WGATE].

Comment 19

[Brendan Eich [:brendan]]

I do not believe adt has any evidence that this fix jeopardizes a candidate
build date, unless netscape.com is planning to release something before drivers
want to release 1.0.2.  I say this fix should go into 1.0.2.

/be

Comment 20

[Michael Buckland]

talked to jag and read previous comments.  renominating for consideration of
team.  jag concurs that patch is safe.  Let's take another look at this.

Comment 21

[Daniel Veditz [:dveditz]]

Approved for the 1.0.2 branch by adt.

Comment 22

[Brian Ryner (not reading)]

checked into the 1.0 branch.

Comment 23

[Vladimir Ermakov]

janc: could you please check with the recent talkback reports if this is still
occuring after the fix has been checked into the branch? I cannot reproduce the
bug neither on old nor on new builds, so I cannot verify if it was fixed.

Comment 24

[Jan Carpenter]

I don't find anything reported in TB since the fix was checked in.

Comment 25

[Vladimir Ermakov]

verifying on branch based on coments

Comment 26

[Vladimir Ermakov]

verifying based on coments