Closed Bug 850571 Opened 11 years ago Closed 11 years ago

crash in nsView::`.* deleting destructor'

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Version:
21 Branch
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla24
Tracking Flags:
Tracking Status
firefox20 --- unaffected
firefox21 - wontfix
firefox22 - affected
firefox23 --- verified
firefox24 --- verified

People

(Reporter: scoobidiver, Assigned: MatsPalmgren_bugz)

References

Details

(4 keywords)

Crash Data

Attachments

(1 file)

Try to crash earlier
854 bytes, patch
roc
: review+
Details | Diff | Splinter Review 
It's #24 top browser crasher in 21.0a2 and #56 in 22.0a1 and was a very low volume crash in previous versions. It first showed up in 21.0a1/20130108 but is discontinuous across builds. The regression range might be:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=605ae260b7c8&tochange=dccab70d8554
I suspect bug 826149.

Some reports have app notes: bp-6ab7de1e-b7f5-4ad8-a2a2-2bb002130111.

Signature 	moz_abort | je_free | nsView::`scalar deleting destructor''(unsigned int) More Reports Search
UUID	55ef665c-df78-479e-a624-bef662130312
Date Processed	2013-03-12 21:18:53
Uptime	3560
Last Crash	1.0 hours before submission
Install Age	2.5 hours since version was first installed.
Install Time	2013-03-12 18:37:56
Product	Firefox
Version	22.0a1
Build ID	20130312031046
Release Channel	nightly
OS	Windows NT
OS Version	6.1.7601 Service Pack 1
Build Architecture	x86
Build Architecture Info	AuthenticAMD family 16 model 4 stepping 3
Crash Reason	EXCEPTION_BREAKPOINT
Crash Address	0x749f1b5f
App Notes 	
AdapterVendorID: 0x1002, AdapterDeviceID: 0x6819, AdapterSubsysID: 32621682, AdapterDriverVersion: 9.2.0.0
D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ 
Processor Notes 	sp-processor07.phx1.mozilla.com_1207:2008
EMCheckCompatibility	True
Adapter Vendor ID	0x1002
Adapter Device ID	0x6819
Total Virtual Memory	4294836224
Available Virtual Memory	3513384960
System Memory Use Percentage	24
Available Page File	22217007104
Available Physical Memory	9777577984

Frame 	Module 	Signature 	Source
0 	mozglue.dll 	moz_abort 	memory/build/jemalloc_config.c:33
1 	mozglue.dll 	je_free 	memory/mozjemalloc/jemalloc.c:6589
2 	xul.dll 	nsView::`scalar deleting destructor' 	
3 	xul.dll 	nsFrame::DestroyFrom 	layout/generic/nsFrame.cpp:675
4 	xul.dll 	nsContainerFrame::DestroyFrom 	layout/generic/nsContainerFrame.cpp:267
5 	xul.dll 	nsMenuPopupFrame::DestroyFrom 	layout/xul/base/src/nsMenuPopupFrame.cpp:1833
6 	xul.dll 	nsFrameList::DestroyFramesFrom 	layout/generic/nsFrameList.cpp:61
7 	xul.dll 	nsPopupSetFrame::DestroyFrom 	layout/xul/base/src/nsPopupSetFrame.cpp:101
8 	xul.dll 	nsContainerFrame::DestroyFrom 	layout/generic/nsContainerFrame.cpp:251
9 	xul.dll 	nsBoxFrame::DestroyFrom 	layout/xul/base/src/nsBoxFrame.cpp:947
10 	xul.dll 	nsDocElementBoxFrame::DestroyFrom 	layout/xul/base/src/nsDocElementBoxFrame.cpp:78
11 	xul.dll 	nsContainerFrame::DestroyFrom 	layout/generic/nsContainerFrame.cpp:251
12 	xul.dll 	nsBoxFrame::DestroyFrom 	layout/xul/base/src/nsBoxFrame.cpp:947
13 	xul.dll 	nsContainerFrame::DestroyFrom 	layout/generic/nsContainerFrame.cpp:251
14 	xul.dll 	nsFrameManager::Destroy 	layout/base/nsFrameManager.cpp:220
15 	xul.dll 	nsCSSFrameConstructor::WillDestroyFrameTree 	layout/base/nsCSSFrameConstructor.cpp:8696
16 	xul.dll 	PresShell::Destroy 	layout/base/nsPresShell.cpp:1086
17 	xul.dll 	nsDocumentViewer::DestroyPresShell 	layout/base/nsDocumentViewer.cpp:4366
18 	xul.dll 	nsDocumentViewer::Destroy 	layout/base/nsDocumentViewer.cpp:1623
19 	xul.dll 	nsDocumentViewer::~nsDocumentViewer 	layout/base/nsDocumentViewer.cpp:583
20 	xul.dll 	nsDocumentViewer::Release 	layout/base/nsDocumentViewer.cpp:555
21 	xul.dll 	nsCOMPtr_base::assign_with_AddRef 	obj-firefox/xpcom/build/nsCOMPtr.cpp:49
22 	xul.dll 	nsDocShell::Destroy 	docshell/base/nsDocShell.cpp:5031
23 	xul.dll 	nsXULWindow::Destroy 	xpfe/appshell/src/nsXULWindow.cpp:480
24 	xul.dll 	nsWebShellWindow::Destroy 	xpfe/appshell/src/nsWebShellWindow.cpp:754
25 	xul.dll 	nsWebShellWindow::RequestWindowClose 	xpfe/appshell/src/nsWebShellWindow.cpp:311
26 	xul.dll 	nsWindow::ProcessMessage 	widget/windows/nsWindow.cpp:4758
27 	xul.dll 	nsWindow::WindowProcInternal 	widget/windows/nsWindow.cpp:4381
28 	xul.dll 	CallWindowProcCrashProtected 	xpcom/base/nsCrashOnException.cpp:32
29 	xul.dll 	nsWindow::WindowProc 	widget/windows/nsWindow.cpp:4333
30 	user32.dll 	InternalCallWinProc 	
31 	user32.dll 	UserCallWinProcCheckWow 	
...

More reports at:
https://crash-stats.mozilla.com/report/list?signature=moz_abort+|+je_free+|+nsView%3A%3A%60scalar+deleting+destructor%27%27%28unsigned+int%29
https://crash-stats.mozilla.com/report/list?signature=moz_abort+|+je_free+|+nsView%3A%3A%60vector+deleting+destructor%27%27%28unsigned+int%29
There's no way that bug 826149 could've caused this. (especially on a broad scale)

That bug just added a tiny early-return in flex container reflow that makes our reflow a no-op if we're more than 200 frames deep.  We have similar early-returns in other reflow methods, too -- that bug was just making nsFlexContainerFrame consistent on that.

(If nsFlexContainerFrame were in the backtraces somewhere, I'd be more inclined to think that commit was related.)
status-firefox23: --- → affected
It's #19 top browser crasher in 21.0b1 and #41 in 22.0a1.
tracking-firefox21: --- → ?
Keywords: topcrash
Tracking for now, as this comes in the top-crash criteria.

Adding QA to see if they can help find the regressing bug here.

ni on Kairo to help with Url's co-orelations.
Flags: needinfo?(kairo)
Keywords: needURLs
Unfortunately I didn't have a chance to look at this today. Ioana, can you please coordinate some testing around this overnight. See if you can find steps to reproduce and a regression window. Thank you.
QA Contact: ioana.budnar
(In reply to Tracy Walker [:tracy] from comment #5)

I am unable to test the following websites for the following reasons.

> 346: https://muisca.dian.gov.co/WebDiligenciamiento/DefGestionFirmasPopup.faces
>   3: https://muisca.dian.gov.co/WebRutMuisca/DefActividadesEconomicas.faces
This is the National Tax and Customs Office of the Republic of Columbia, requiring authorized access to enter. 

>  18: http://3s.gamemania.co.kr/Game/GameStart
>   6: http://3s.kr.gameclub.com/Game/GameStart
Fails to load, prompting me with a message in Korean roughly translating to "Please try again later"

>  10: http://beta.gface.com/
Website to a closed Beta.

>   5: https://marketq.fs.ml.com/Launch
MarketQ Securities trading website to which I'm unable to get authorized access.

>   4: http://www.qooqlle.com/
Parked domain

>   4: https://etrade.hdfcsec.com//homepage/Intermediate.jsp
HDFC Securities trading website to which I'm unable to get authorized access

That just leaves the following websites which I've as of yet been able to reproduce a crash.
> 13 	https://www.facebook.com/
> 4 	http://www.facebook.com/
> 3 	http://www.theexgirlfriends.com/
> 3 	http://www.gangkhun.com/index.php
> 3 	https://www.google.com/

Since our highest correlated website is Columbia's tax and customs website perhaps we could perform some outreach to Columbian users or the l10n community to assist.
Sent email to one of our contributors in Colombia to see if they can help us reproduce the site in question.
We can also perform outreach to: 

"buenas tardes, la pagina es www.dian.gov.co, al realizar el proceso de firma de una declaracion, me indica que si debo ejecutar un procedimiento, lo realizo pero de igual forma no se me soluciona el problema, mi correo es monicaruiz1716@hotmail.com"

"good afternoon, is www.dian.gov.co page, to make the process of signing a declaration, tells me that if I run a process, but I do it the same way I can not help, my email is monicaruiz1716 @ hotmail.com"
Is there an easier tool/process to send to an impacted user than mozregression?
Flags: needinfo?(jbecerra)
(In reply to Alex Keybl [:akeybl] from comment #9)
> Is there an easier tool/process to send to an impacted user than
> mozregression?

In terms of isolating a regression range it doesn't get any easier than mozregression.
Last week I contacted Gloria in Mozilla Colombia and she was going to do some outreach. I've also sent email the person in comment #8, but I haven't heard back from that person yet. As soon as I do I will follow up.
Flags: needinfo?(jbecerra)
Removing myself as QA contact and adding Juan, since and he seems to be doing the work here.

Let me know if you still want the QA team to try and find steps for this bug.
QA Contact: ioana.budnar → jbecerra
(In reply to Ioana Budnar [QA] from comment #12)
> Removing myself as QA contact and adding Juan, since and he seems to be
> doing the work here.
> 
> Let me know if you still want the QA team to try and find steps for this bug.

Ioana, Juan was unable to reproduce the issue and has done the outreach.But considering there are no other leads on this bug if you can still try and get us steps or the regressing bug here it will be very helpful
(In reply to bhavana bajaj [:bajaj] from comment #13)
> (In reply to Ioana Budnar [QA] from comment #12)
> > Removing myself as QA contact and adding Juan, since and he seems to be
> > doing the work here.
> > 
> > Let me know if you still want the QA team to try and find steps for this bug.
> 
> Ioana, Juan was unable to reproduce the issue and has done the outreach.But
> considering there are no other leads on this bug if you can still try and
> get us steps or the regressing bug here it will be very helpful

Based on provided URLs the only lead we have right now is https://muisca.dian.gov.co which outweighs all other URLs combined. Unfortunately, this website is only accessible to Columbians. In my opinion, outreach is our best and only option at this point. I think Ioana's time would be better spent on other more critical bugs.
ccing :roc on this to get some eyes on this issue & see if there is anything obvious that he can help identify here, given we had no luck reproducing the issue and are running out of time to fix this in Fx21 timeframe .

:roc, anything striking here ?
Looks like we're crashing destroying a popup menu's frame. I don't see anything related to that in the postulated regression range. Mats, did you change anything related to that?
Not that I can remember.  I looked through the landings in the range and nothing
stands out in particular.  The crash data appears to be 100% on Windows, fwiw.

I put a breakpoint in nsPopupSetFrame::DestroyFrom and browsed
https://muisca.dian.gov.co for a while, I only hit it with this STR:
1. load a page that contains a form, e.g.
   https://muisca.dian.gov.co/WebArquitectura/DefLogin.faces
2. click submit
3. reload the page
4. this brings up the "To display this page, Firefox must send..." 
5. click Cancel or Resend

When the Resend popup window is destroyed I get roughly the same stack at the
breakpoint (on Linux) as in the crash reports.

I tried stressing that STR for a while on Windows but no luck...
:Mats, since you were close to reproducing the crash do you think we can do some hardening here to mitigate the issue ?
Assignee: nobody → matspal
Heh, I was never anywhere near reproducing the crash ;-)  It was merely a suggestion
of some steps that might be worth testing for QA.
DIAN is a government entity and  I need a valid user to reproduce this bug. I have asked for a test user.
(In reply to Gloria Meneses from comment #22)
> DIAN is a government entity and  I need a valid user to reproduce this bug.
> I have asked for a test user.

Thanks Gloria,please keep us posted at the earliest for any leads you may have heard.
There's not much I can do here without STR.
Keywords: qawanted
Since bug 865569(which may help crash easily and get us reliable STR)  landed on aurora, I am adding back qawanted here to see if we can get some testing on the latest aurora build based on :Mats recommendendation in comment# 17
It's #27 browser crasher in 21.0b5 and #41 in 22.0a2 so not a top crasher.
Keywords: topcrash
Crash Signature: [@ moz_abort | je_free | nsView::`scalar deleting destructor''(unsigned int) ] [@ moz_abort | je_free | nsView::`vector deleting destructor''(unsigned int) ] → [@ moz_abort | je_free | nsView::`scalar deleting destructor''(unsigned int) ] [@ moz_abort | je_free | nsView::`vector deleting destructor''(unsigned int) ] [@ moz_abort | arena_run_reg_dalloc | arena_dalloc_small | arena_dalloc | je_free | nsView::`ve…
Can someone please post the URLs for "Firefox 22.0a2 Crash Report
[@ nsView::Destroy() ]", e.g. bp-b17ae3c5-074d-4ced-b413-ecf9f2130507
Thanks.
Keywords: needURLs
I've been trying to test with Firefox 22.0a2 around the proposed steps in comment 17 for a few days now but haven't been able to reproduce a crash. Dropping qawanted for the time being, please re-add if there's something more we can do.

Juan, did you receive any response from you community outreach?
Flags: needinfo?(jbecerra)
Keywords: qawanted → steps-wanted
Crash Signature: nsView::`vector deleting destructor''(unsigned int) ] → nsView::`vector deleting destructor''(unsigned int) ] [@ nsView::Destroy()]
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #31)
> I've been trying to test with Firefox 22.0a2 around the proposed steps in
> comment 17 for a few days now but haven't been able to reproduce a crash.
> Dropping qawanted for the time being, please re-add if there's something
> more we can do.
> 
> Juan, did you receive any response from you community outreach?

I did not get any replies. I don't know if Gloria got any feedback from the people she contacted either.
Flags: needinfo?(jbecerra)
No guys... I have not had an answer yet :(  I have sent 3 emails and I have not an answer yet. I will try calling to that office but I have to look for the phone number.
It's #15 top crasher in 21.0b7, #19 in 22.0b1 but oddly doesn't happen in 21.0.

More reports at:
https://crash-stats.mozilla.com/report/list?signature=nsView%3A%3ADestroy%28%29
status-firefox24: --- → affected
tracking-firefox22: --- → ?
Keywords: topcrash
Attached patch Try to crash earlier — — Splinter Review 
Perhaps we should try something like this -- the theory is that
someone calls nsView::Destroy() on a view that's owned by a frame
and when that frame is later destroyed, it'll Destroy the view again
(which will crash with one of the signatures in this bug).

So this should catch that first bad call to nsView::Destroy(),
if indeed that's what happens.  What do you think?
Attachment #751518 - Flags: review?(roc)
Whiteboard: [leave open]
There's now a couple of crash reports for 21.0 (involving nsComboboxControlFrame):
bp-fe04a0fa-a73c-49db-86b5-110c82130520
bp-63238eb6-2977-41dc-a953-c04952130517

I also found one involving a nsSubDocumentFrame:
bp-cba32831-d29a-4a1c-90de-34be82130518

I also note that all crashes so far is destroying the shell (PresShell::Destroy
on the stack).  It appears any type of frame that can have a view can be the
victim.
(In reply to Scoobidiver from comment #36)
> It's #15 top crasher in 21.0b7, #19 in 22.0b1 but oddly doesn't happen in
> 21.0.

We know that FF21 was affected on beta but not release, and we don't have evidence to believe that this is build-specific. Can we assume that release builds are therefore unaffected?

What do others think?
tracking-firefox22: ? → -
> Can we assume that release builds are therefore unaffected?

No, comment 39 links a couple of FF21 crash incidents.
There were no significant code change between FF21b7 and FF21 really,
so I see no reason to believe FF21 is unaffected.
I assume the new signature introduced by the investigation patch is mozalloc_abort(char const* const) | NS_DebugBreak | nsView::Destroy(). See https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char+const*+const%29+|+NS_DebugBreak+|+nsView%3A%3ADestroy%28%29
Crash Signature: nsView::`vector deleting destructor''(unsigned int) ] [@ nsView::Destroy()] → nsView::`vector deleting destructor''(unsigned int) ] [@ nsView::Destroy()] [@ mozalloc_abort(char const* const) | NS_DebugBreak | nsView::Destroy() ]
Yes, thanks.  Let me know if you see any interesting URLs in those that could
help us reproduce it.
I wonder if these stacks are just bug 871942 except they don't crash in RequestWindowClose and keep going and all the stacks have the plugin part of the stack missing.
Blocks: 875253
Some comments talk about closing a window or Firefox.

There have been no crashes with the "mozalloc_abort(char const* const) | NS_DebugBreak | nsView::Destroy()" signature since 24.0a1/20130601.
The working range might be (assumption of 2 days):
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3c6f2394995d&tochange=18fc62fd8dcc

The investigation patch should be backed out from m-c.
status-firefox24: affected → unaffected
That's good, but I don't see anything in that range that seems likely to have
fixed it.  Oh, well...

> The investigation patch should be backed out from m-c.

Yes, will do.
Removed the diagnostic code:
https://hg.mozilla.org/integration/mozilla-inbound/rev/0fc683007248
Whiteboard: [leave open]
WORKSFORME, per comment 46.  Please reopen this bug if a crash occurs again
in builds 24.0a1/20130602 or later.  Thanks.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
The volume of this crash on nightly was low enough that I think we should watch to see if we get a similar drop in aurora and beta to confirm what we've found here.
Probably this bug:
bp-e20faed6-7031-43ab-9ed5-d33982130614
bp-30a87fd9-1919-436f-8969-cffcd2130614
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
(In reply to Mats Palmgren (on vacation) from comment #52)
> Probably this bug:
> bp-e20faed6-7031-43ab-9ed5-d33982130614
> bp-30a87fd9-1919-436f-8969-cffcd2130614
Those are on 64-bit Windows builds and intermittent.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → WORKSFORME
I can reproduce this in beta. If anybody is interested. Steps don't work in nightly though.
(In reply to kalviskajaks from comment #54)
> I can reproduce this in beta. If anybody is interested. Steps don't work in
> nightly though.

Yes, please share your steps to reproduce.
1) Open firefox
2) Go to https://www.youtube.com/watch?v=RLFzT99mFVA
3) Close firefox
4) Crash
(In reply to kalviskajaks from comment #56)
> 1) Open firefox
> 2) Go to https://www.youtube.com/watch?v=RLFzT99mFVA
> 3) Close firefox
> 4) Crash

Here is the crash report 
https://crash-stats.mozilla.com/report/index/bp-927da385-5b14-4af5-9a40-006902130624
More testing done, disabling flash in my case stops the crash from happening.
(In reply to kalviskajaks from comment #54)
> I can reproduce this in beta. If anybody is interested. Steps don't work in
> nightly though.

This would seem to confirm comment 49. Would you be willing to do some testing to try to narrow down when this was fixed for you? Does this happen in a Firefox Nightly 24.0a1 build after 20130602? How about before? 

Note that unless a definitive fix range can be tracked down then this will likely ride the trains and exist until Firefox 24 is released (~12 weeks).
I've had no luck trying to reproduce using the steps in comment 56.
2013-05-24

No crash

2013-05-23

Crash
(In reply to kalviskajaks from comment #61)
> 2013-05-24
> 
> No crash
> 
> 2013-05-23
> 
> Crash

These are Nightly 24.0a1 build dates in response to Anthony. just to clarify.
The working range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=00b264c7cced&tochange=df526497d949

Can you narrow down the working range using https://github.com/mozilla/mozregression and eventually mozilla-inbound?
Flags: needinfo?(kalviskajaks)
(In reply to Scoobidiver from comment #63)
> The working range is:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=00b264c7cced&tochange=df526497d949
> 
> Can you narrow down the working range using
> https://github.com/mozilla/mozregression and eventually mozilla-inbound?

Im sorry but this is getting a bit complicated, so if somebody needs the info, they are gonna need to write me some steps to follow.. i tried to use mozregression but i think im doing something wrong. What i did.
1)Installed mozillaBuild
2)Run C:\mozilla-build\start-l10n.bat
3)easy_install mozregression
4)mozregression --good=2013-05-24 --bad=2013-05-23  (is that correct?)
5)It asked me if i want to "bisect further by fetching repository and building", I said yes
6)it did run for a while doing some stuff
7) Than come up a lot of errors, which looked like
======================================
Building.. 
Nonzero exit code from make -f client.mk build
client.mk:90 Pymake is required to build on windows run |./match build| to automtically use pymake. or invoke pymake directly via pyton build/pymake/make.py.. Stop.

This build failed! 
and some other stuff after that
=========================================
nothing else happened. i left it run for some hours and nothing else except the errors was showing up... So unless anybody can instruct me, cant give more info. Very sorry.
(In reply to Scoobidiver from comment #63)
> The working range is:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=00b264c7cced&tochange=df526497d949

Bug 871942 landed in that range, and in comment 45 I previously surmised that it might fix this bug. Combining this range with the fact that plugins (Flash) are necessary to reproduce this we now have pretty good evidence for bug 871942 fixing this.
Depends on: 871942
Resolution: WORKSFORME → FIXED
(In reply to kalviskajaks from comment #64)
> This build failed! 
> and some other stuff after that
> =========================================
> nothing else happened. i left it run for some hours and nothing else except
> the errors was showing up... So unless anybody can instruct me, cant give
> more info. Very sorry.

It's trying to build Firefox from source, but you need to jump through even more hoops for that to work.

If we really want to narrow this down further you can download mozilla-inbound builds from http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32/ they go back to may 22, and old builds get removed so our ability to do this will quickly go away.
status-firefox24: unaffected → fixed
Flags: needinfo?(kalviskajaks)
Keywords: regressionwindow-wanted, steps-wanted → reproducible
Target Milestone: --- → mozilla24
(In reply to Timothy Nikkel (:tn) from comment #66)
> It's trying to build Firefox from source, but you need to jump through even
> more hoops for that to work.
> 
> If we really want to narrow this down further you can download
> mozilla-inbound builds from
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-
> inbound-win32/ they go back to may 22, and old builds get removed so our
> ability to do this will quickly go away.

Thank you for giving the link. if anybody is still interested 

http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32/1369350711/

crash

http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32/1369351430/

no crash
(In reply to kalviskajaks from comment #67)
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-
> inbound-win32/1369350711/
> crash
> http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-
> inbound-win32/1369351430/
> no crash
The working range is:
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ab0ec721fc96&tochange=1fab16a30ed5
So bug 871942 is indeed the fix.
Thanks for your cooperation!
Keywords: verifyme
QA was never able to reproduce this issue, but kalviskajaks could.

kalviskajaks, we should have our next Beta build available on Monday. Would you be able to test for this crash again? When available the builds will appear here:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/23.0b2-candidates/build1/

Thanks in advance.
We should also make sure that the crash numbers look good in case we only fixed one case.
ok will test it out on monday.
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #70)
> QA was never able to reproduce this issue, but kalviskajaks could.
> 
> kalviskajaks, we should have our next Beta build available on Monday. Would
> you be able to test for this crash again? When available the builds will
> appear here:
> ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/23.0b2-candidates/
> build1/
> 
> Thanks in advancE
Tried it. seems to be fine, didnt crash.
There are no Firefox 23 and 24 crashes more recent than 06/18 for any of the signatures in this bug:
https://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&reason_type=contains&date=2013-07-02&range_value=28&range_unit=days&hang_type=any&process_type=any&signature=moz_abort+%7C+je_free+%7C+nsView%3A%3A%60scalar+deleting+destructor%27%27%28unsigned+int%29
https://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&reason_type=contains&date=2013-07-02&range_value=28&range_unit=days&hang_type=any&process_type=any&signature=moz_abort+%7C+je_free+%7C+nsView%3A%3A%60vector+deleting+destructor%27%27%28unsigned+int%29
https://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&reason_type=contains&date=2013-07-02&range_value=28&range_unit=days&hang_type=any&process_type=any&signature=moz_abort+%7C+arena_run_reg_dalloc+%7C+arena_dalloc_small+%7C+arena_dalloc+%7C+je_free+%7C+nsView%3A%3A%60vector+deleting+destructor%27%27%28unsigned+int%29
https://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&reason_type=contains&date=2013-07-02&range_value=28&range_unit=days&hang_type=any&process_type=any&signature=nsView%3A%3ADestroy%28%29
https://crash-stats.mozilla.com/report/list?product=Firefox&query_search=signature&query_type=contains&reason_type=contains&date=2013-07-02&range_value=28&range_unit=days&hang_type=any&process_type=any&signature=mozalloc_abort%28char+const%2A+const%29+%7C+NS_DebugBreak+%7C+nsView%3A%3ADestroy%28%29
Status: RESOLVED → VERIFIED
status-firefox23: fixed → verified
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: