Closed Bug 1279216 Opened 3 years ago Closed 3 years ago

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


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

48 Branch
Windows 7



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


(Reporter: philipp, Assigned: surkov)



(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.
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.

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!
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.