498530 - Firefox crashes [@ memmove | nsTArray_base::ShiftData | nsTArray<nsAutoPtr<PresShell::nsDelayedEvent> >::RemoveElementsAt] after updating text box triggering update of AJAX based page

Status: VERIFIED FIXED

(Core :: General, defect)

Description

[Michael Rollins]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.9) Gecko/2009050519 Iceweasel/3.0.6 (Debian-3.0.6-1)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b99) Gecko/20090605 Firefox/3.5b99 (.NET CLR 3.5.30729)

Firefox crashes after adding attendee by name (not smtp address) in Scalix Web Access (SWA) in Scalix 11.4.4 installation.

Reproducible: Always

Steps to Reproduce:
1.Log into http://mail.bamail.net/webmail with username: firefox and password: firefox
2.Type CTRL-SHIFT-A or File->New->Appointment in the popup window that appears
3. Click the scheduling tab
4. Type the name "mozilla" (without quotes) into the text box where it says "Click here to add a name"
5. Hit tab to change the focus from the text box
Actual Results:  
Firefox crashes.

Expected Results:  
The text box should update and the firefox should allow the user to click Save at the top of the page.

Worked in Firefox 3.5b4, crashes in Firefox 3.5b99.
No changes to server, all saved content/cookies etc cleared before reproducing crash.

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

Can you try this with the JIT off? Go into about:config and flip the value of javascript.options.jit.content to false.

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

works for me, OSX, latest branch nightly

Error: setting a property that has only a getter
Source File: http://mail.bamail.net/webmail/wnd_ComposeAppt.jsp?locale=en_US
Line: 1

shows in the error console, fwiw

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

Reporter: grab a latest nightly from:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.1/

and see if it's fixed?

Comment 4

[Michael Rollins]

The issue still occurs in the latest nightly.

With respect to comment 2, the error in the console has been there for some time without causing any noticeable issues with Firefox.

Turning off the JIT compiler does not resolve the issue.

Submitted two crash dumps (one with JIT enabled and one with it disabled) with a note to associate it with this bug.

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

Can you post the link to the crash reports here? I'm assuming you're using Windows?

Comment 6

[IlkkaP]

I can reproduce this with Gecko/20090616 Shiretoko/3.5pre.

>	00841110()	
 	xul.dll!nsAutoPtr<txTemplateItem>::~nsAutoPtr<txTemplateItem>()  Line 105	C++
 	xul.dll!txLocPathPattern::Step::`scalar deleting destructor'()  + 0x9 bytes	C++
 	xul.dll!nsTArrayElementTraits<txLocPathPattern::Step>::Destruct(txLocPathPattern::Step * e=0x6342d290)  Line 198	C++
 	xul.dll!nsTArray<nsAutoPtr<PresShell::nsDelayedEvent> >::DestructRange(unsigned int start=0, unsigned int count=1)  Line 763 + 0x6 bytes	C++
 	xul.dll!nsTArray<nsAutoPtr<PresShell::nsDelayedEvent> >::RemoveElementsAt(unsigned int start=0, unsigned int count=1)  Line 600	C++
 	xul.dll!nsTArray<nsAutoPtr<PresShell::nsDelayedEvent> >::RemoveElementAt(unsigned int index=0)  Line 606	C++
 	xul.dll!PresShell::FireOrClearDelayedEvents(int aFireEvents=9809920)  + 0x14c9f2 bytes	C++
 	xul.dll!FireOrClearDelayedEvents(nsTArray<nsCOMPtr<nsIDocument> > & aDocuments={...}, int aFireEvents=1)  Line 7492	C++
 	xul.dll!nsDelayedEventDispatcher::Run()  Line 7508 + 0xf bytes	C++
 	xul.dll!nsThread::ProcessNextEvent(int mayWait=1, int * result=0x002ef578)  Line 511	C++
 	xul.dll!nsBaseAppShell::Run()  Line 169	C++
 	xul.dll!nsAppStartup::Run()  Line 194	C++
 	xul.dll!XRE_main(int argc=, char * * argv=, const nsXREAppData * aAppData=)  Line 3300	C++
 	xul.dll!nsLocalFile::GetParent(nsIFile * * aParent=0x62c0c8cb)  Line 2250 + 0x94 bytes	C++
 	xul.dll!nsCOMPtr_base::~nsCOMPtr_base()  Line 82	C++
 	firefox.exe!wmain(int argc=1, wchar_t * * argv=0x00819100)  Line 110 + 0xe6 bytes	C++
 	firefox.exe!__tmainCRTStartup()  Line 591 + 0x19 bytes	C
 	kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes	
 	ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes	
 	ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

Looks to maybe be cycle collector related, and windows-only?

Comment 8

[AL]

Hi guys !
Maybe the same issue like this one :
https://bugzilla.mozilla.org/show_bug.cgi?id=498305

Comment 9

[Michael Rollins]

Here are the links to my crash reports:
JIT Enabled: http://crash-stats.mozilla.com/report/index/9a4a1c9f-cef8-4369-b32f-b9bc62090616
JIT Disabled: http://crash-stats.mozilla.com/report/index/adf39101-5aaa-43e8-9b6d-77a972090616

Comment 10

[Michael Rollins]

I haven't tested 3.5pre on any linux boxes.  I'll try later.

Comment 11

[Martijn Wargers (dead)]

I can reproduce this:
http://crash-stats.mozilla.com/report/index/f22fe199-046d-4581-8aba-9d6372090616?p=1
0  	mozcrt19.dll  	memmove  	 MEMCPY.ASM:188
1 	xul.dll 	nsTArray_base::ShiftData 	obj-firefox/xpcom/build/nsTArray.cpp:173
2 	xul.dll 	nsTArray<nsAutoPtr<PresShell::nsDelayedEvent> >::RemoveElementsAt 	obj-firefox/dist/include/nsTArray.h:664
3 	xul.dll 	nsTArray<nsAutoPtr<PresShell::nsDelayedEvent> >::RemoveElementAt 	obj-firefox/dist/include/nsTArray.h:669
4 	xul.dll 	xul.dll@0x335743 	
5 	xul.dll 	FireOrClearDelayedEvents 	content/base/src/nsDocument.cpp:7508
6 	xul.dll 	nsDelayedEventDispatcher::Run 	content/base/src/nsDocument.cpp:7525
7 	xul.dll 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:510
8 	xul.dll 	nsBaseAppShell::Run 	widget/src/xpwidgets/nsBaseAppShell.cpp:170
9 	xul.dll 	nsAppStartup::Run 	toolkit/components/startup/src/nsAppStartup.cpp:193
10 	nspr4.dll 	PR_GetEnv 	
11 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:110
12 	firefox.exe 	firefox.exe@0x21a7 	
13 	kernel32.dll 	kernel32.dll@0x17076 

I attached zipped up testcase2 in bug 494617 that seems to trigger the same stacktrace as this crash, so it seems likely related to this. I guess the patch in bug 494617 doesn't fix this crash, as I initially thought the 2nd testcase was related to that bug.

Comment 12

[Martijn Wargers (dead)]

Attachment: zipped up testcase2 (uses enhanced privileges for accessibility code)

This is the zipped up testcase2 that I mentioned. It uses enhanced privileges, so you need to download it to your computer and give it the privileges it asks for.
I hit the crash while keeping the tab key pressed on the testcase.
I haven't looked for a regression range yet, I'll look for it later, in a few hours (if someone else does it before me, thanks).

Comment 13

[Boris Zbarsky [:bzbarsky]]

Almost certainly a regression from bug 333198.

This code in PresShell::FireOrClearDelayedEvents looks suspicious to me:

6784     while (mDelayedEvents.Length() && !doc->EventHandlingSuppressed()) {
6785       mDelayedEvents[0]->Dispatch(this);
6786       mDelayedEvents.RemoveElementAt(0);
6787     }

What ensures that the Dispatch() call won't clear mDelayedEvents (e.g. via reentering this function), or even call Destroy() on the presshell?  I think this would be better written as:

  while (!mIsDestroying && mDelayedEvents.Length() &&
         !doc->EventHandlingSuppressed()) {
    nsAutoPtr<nsDelayedEvent> ev = mDelatedEvents[0].forget();
    mDelayedEvents.RemoveElementAt(0);
    ev->Dispatch(this);
  }

or something along those lines.  Olli, thoughts?

Comment 14

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #13)
>   while (!mIsDestroying && mDelayedEvents.Length() &&
>          !doc->EventHandlingSuppressed()) {
>     nsAutoPtr<nsDelayedEvent> ev = mDelatedEvents[0].forget();
>     mDelayedEvents.RemoveElementAt(0);
>     ev->Dispatch(this);
>   }
> 
> or something along those lines.  Olli, thoughts?
Makes sense.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch to that effect

Comment 16

[Martijn Wargers (dead)]

Attachment: correct zipped up testcase2

Sorry, I uploaded a wrong zipped up testcase, this one does crash.
Not that it doesn't seem to crash in the latest trunk build, presumably, because of the check-in of the new focus manager patch, but it doesn at least crash in a 2009-06-06 build.

Comment 17

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 383498 [details] [diff] [review]
Patch to that effect

Doesn't compile on OSX

Comment 18

[Olli Pettay [:smaug][[e-mail]]]

Attachment: compiles

Fixes the latest testcase

Comment 19

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 383507 [details] [diff] [review]
compiles

This is bz's patch + a small compilation fix.

Comment 20

[Boris Zbarsky [:bzbarsky]]

Pushed http://hg.mozilla.org/mozilla-central/rev/341423c8e1f6

Comment 21

[Olli Pettay [:smaug][[e-mail]]]

I uploaded the patch to tryserver (using 1.9.1 hg repo).
If anyone who can reproduce the original crash could test the build.
It will appear here https://build.mozilla.org/tryserver-builds/?C=M;O=D suppression_crash in its name.

Comment 22

[Michael Rollins]

Verified the issue has been resolved with the suppression_crash build.
No crash and behavior is the same as Firefox 3.5b4.

Comment 23

[Mike Beltzner [:beltzner, not reading bugmail]]

bz: should we block 3.5 release on this? Not sure how common a pattern it is. This is our first report.

Comment 24

[Boris Zbarsky [:bzbarsky]]

I don't know how common this is... but the fact that we're basically running afoul of touching memory we shouldn't worries me.  It's a very safe patch, so I think we should take in on branch if we're going to take anything else, at the very least.

Comment 25

[Boris Zbarsky [:bzbarsky]]

Pushed http://hg.mozilla.org/releases/mozilla-1.9.1/rev/e2dd2ceb4ea9 and http://hg.mozilla.org/releases/mozilla-1.9.1/rev/f9454a3baf9c

Comment 26

[Florian von Kurnatowski]

Well, not sure if this plays a role for your decision-making process, but it is basically a red flag for 3.5 for our AJAX-based Email and calendaring solution.

We have 10000s of users using Scalix Web Access on Firefox for their desktop mail and calendar and a very basic usecase is affected, i.e. adding an attendee to an appointment, see https://bugzilla.scalix.com/show_bug.cgi?id=20116 for details. 

I am not sure if we could drop-in a code-level workaround, but if that cannot be done in a simple and safe and sensical way, we have to publicly declare FF3.5 unsupported and unuseable for it.

Furthermore, given the JS around the area where the problem occurs is far away from being extremely complex, I must assume that other AJAX-based apps will be affected as well.

So at least in my world, all-in-all, it would qualify as a blocker for a release.

(This bug was filed by Michael as a followup of our QA regression testing of the product on upcoming browser versions)

Comment 27

[Nochum Sossonko [:Natch]]

This was pushed to 1.9.1 (see keyword 'verified1.9.1') and will be included in 3.5 RC2.

Comment 28

[Tony Chung [:tchung]]

Verified fix on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1) Gecko/20090616 Firefox/3.5
and Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1) Gecko/20090616 Firefox/3.5

Testcase from comment 0 and comment 16 pass on rc2build2.

Comment 29

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verification on Linux would be fine too since it happens on all platforms.

Comment 30

[Tony Chung [:tchung]]

Also verified on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1) Gecko/20090616 Firefox/3.5

Comment 31

[Samuel Sidler (old account; do not CC)]

This doesn't need to block 1.9.1.1 since, uh, it's already fixed. :) Please renom if I missed something.