Closed Bug 1279216 Opened 8 years ago Closed 8 years ago

Crash in operator new | nsTArray_base<T>::ShiftData<T> | nsTArray_Impl<T>::InsertElementAt<T> | mozilla::a11y::Accessible::InsertChildAt

Categories

(Core :: Disability Access APIs, defect, P1)

48 Branch
x86
Windows 7
defect

Tracking

()

RESOLVED FIXED
Tracking Status
e10s - ---
firefox47 --- unaffected
firefox48 + fixed
firefox49 --- fixed
firefox50 --- fixed

People

(Reporter: philipp, Assigned: surkov)

References

Details

(Keywords: crash, regression, topcrash)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-dc36bfc6-7ee0-4861-97bd-e05fe2160609.
=============================================================
Crashing Thread (0)
Frame 	Module 	Signature 	Source
0 	msvcr120.dll 	operator new(unsigned int) 	
1 	xul.dll 	nsTArray_base<nsTArrayInfallibleAllocator, nsTArray_CopyWithMemutils>::ShiftData<nsTArrayInfallibleAllocator>(unsigned int, unsigned int, unsigned int, unsigned int, unsigned int) 	obj-firefox/dist/include/nsTArray-inl.h:272
2 	xul.dll 	nsTArray_Impl<nsTableColFrame*, nsTArrayInfallibleAllocator>::InsertElementAt<nsTableColFrame*, nsTArrayInfallibleAllocator>(unsigned int, nsTableColFrame*&&) 	obj-firefox/dist/include/nsTArray.h:1407
3 	xul.dll 	mozilla::a11y::Accessible::InsertChildAt(unsigned int, mozilla::a11y::Accessible*) 	accessible/generic/Accessible.cpp:2071
4 	xul.dll 	mozilla::a11y::HyperTextAccessible::InsertChildAt(unsigned int, mozilla::a11y::Accessible*) 	accessible/generic/HyperTextAccessible.cpp:1916
5 	xul.dll 	mozilla::a11y::Accessible::InsertAfter(mozilla::a11y::Accessible*, mozilla::a11y::Accessible*) 	accessible/generic/Accessible.h:390
6 	xul.dll 	mozilla::a11y::DocAccessible::ProcessContentserted(mozilla::a11y::Accessible*, nsIContent*) 	accessible/generic/DocAccessible.cpp:1827
7 	xul.dll 	mozilla::a11y::NotificationController::WillRefresh(mozilla::TimeStamp) 	accessible/base/NotificationController.cpp:319
8 	xul.dll 	nsRefreshDriver::Tick(__int64, mozilla::TimeStamp) 	layout/base/nsRefreshDriver.cpp:1698
9 	xul.dll 	mozilla::RefreshDriverTimer::TickDriver(nsRefreshDriver*, __int64, mozilla::TimeStamp) 	layout/base/nsRefreshDriver.cpp:274
10 	xul.dll 	mozilla::RefreshDriverTimer::TickRefreshDrivers(__int64, mozilla::TimeStamp, nsTArray<RefPtr<nsRefreshDriver> >&) 	layout/base/nsRefreshDriver.cpp:246
11 	xul.dll 	mozilla::RefreshDriverTimer::Tick(__int64, mozilla::TimeStamp) 	layout/base/nsRefreshDriver.cpp:264
12 	xul.dll 	mozilla::VsyncRefreshDriverTimer::RunRefreshDrivers(mozilla::TimeStamp) 	layout/base/nsRefreshDriver.cpp:588
13 	xul.dll 	mozilla::BaseTimeDuration<mozilla::TimeDurationValueCalculator>::FromMilliseconds(double) 	obj-firefox/dist/include/mozilla/TimeStamp.h:132
14 	xul.dll 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp:994

[Tracking Requested - why for this release]:
this crash signature is regressing in 48 builds - in early data for 48.0b1 this signature is at #10 with 1.2% of all crashes.
hi alexander, is this related to the work in bug 1260494?
Flags: needinfo?(surkov.alexander)
(In reply to [:philipp] from comment #1)
> hi alexander, is this related to the work in bug 1260494?

not sure, in what ways? it looks same as bug 1276857, might be a dupe actually.
Flags: needinfo?(surkov.alexander)
Crash Signature: [@ operator new | nsTArray_base<T>::ShiftData<T> | nsTArray_Impl<T>::InsertElementAt<T> | mozilla::a11y::Accessible::InsertChildAt] → [@ operator new | nsTArray_base<T>::ShiftData<T> | nsTArray_Impl<T>::InsertElementAt<T> | mozilla::a11y::Accessible::InsertChildAt] [@ msvcr120.dll@0xf189 | nsTArray_base<T>::ShiftData<T> | nsTArray_Impl<T>::InsertElementAt<T> | mozilla::a11y::Accessible…
Hey David, these signatures are showing up as 16 and 17 top signatures in beta with e10s. Wondering why a11y stacks would show up here.

https://crash-stats.mozilla.com/search/?product=Firefox&version=48.0b1&e10s_cohort=test&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature
Flags: needinfo?(dbolter)
They also show up under non-e10s, so non-e10s specific.
tracking-e10s: --- → -
(In reply to Jim Mathies [:jimm] from comment #4)
> They also show up under non-e10s, so non-e10s specific.

s/non/not
Phew! That would have been weird if it was e10s on in 48.

Alex owns the similar bug (comment 2) so let's put this bug under his care.
Assignee: nobody → surkov.alexander
Flags: needinfo?(dbolter)
Alexander, any news on this bug? Thanks
Tracking as it is a top crash!
Flags: needinfo?(surkov.alexander)
Keywords: topcrash
(In reply to Sylvestre Ledru [:sylvestre] [PTO until July 18th] from comment #7)
> Alexander, any news on this bug? Thanks
> Tracking as it is a top crash!

no news so far, I'm going to get closer to bug 1276857 this week, and then let's see if it helps this one.
Flags: needinfo?(surkov.alexander)
Priority: -- → P1
Depends on: 1276857
Waiting for uplift in bug 1276857 still. We should try to get these fixes in for beta 9 next Monday.
Looks like bug 1276857 was uplifted a couple of days ago.
yes crashes with this signature have ceased in 48.0b9 after the patch from bug 1276857 has landed. thanks for fixing it!
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.