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)
Tracking
()
RESOLVED
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.
Reporter | ||
Comment 1•8 years ago
|
||
hi alexander, is this related to the work in bug 1260494?
Flags: needinfo?(surkov.alexander)
Assignee | ||
Comment 2•8 years ago
|
||
(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)
Reporter | ||
Updated•8 years ago
|
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…
Comment 3•8 years ago
|
||
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)
Comment 4•8 years ago
|
||
They also show up under non-e10s, so non-e10s specific.
tracking-e10s:
--- → -
Comment 5•8 years ago
|
||
(In reply to Jim Mathies [:jimm] from comment #4) > They also show up under non-e10s, so non-e10s specific. s/non/not
Comment 6•8 years ago
|
||
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)
Updated•8 years ago
|
status-firefox49:
--- → affected
status-firefox50:
--- → affected
Comment 7•8 years ago
|
||
Alexander, any news on this bug? Thanks Tracking as it is a top crash!
Assignee | ||
Comment 8•8 years ago
|
||
(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)
Assignee | ||
Updated•8 years ago
|
Priority: -- → P1
Updated•8 years ago
|
status-firefox47:
--- → unaffected
Comment 9•8 years ago
|
||
Waiting for uplift in bug 1276857 still. We should try to get these fixes in for beta 9 next Monday.
Comment 10•8 years ago
|
||
Looks like bug 1276857 was uplifted a couple of days ago.
Reporter | ||
Comment 11•8 years 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.
Description
•