Closed Bug 1374984 Opened 8 years ago Closed 8 years ago

Crash in <T>::operator() | mozilla::detail::RunnableFunction<T>::Run

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Version:
56 Branch
Platform:
Unspecified
Windows 10
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1374792
Tracking Flags:
Tracking Status
firefox56 --- affected

People

(Reporter: calixte, Unassigned)

Details

(Keywords: crash, Whiteboard: aes+)

Crash Data

This bug was filed from the Socorro interface and is report bp-06e31616-bcb7-491a-b88e-8d6820170620. ============================================================= There are 29 crashes in nightly 56 with buildid 20170620030208. There are 10 crashes for signature "CoMarshalInterface" and 30 for "CDestObjectWrapper::MarshalInterface". :aklotz, could you investigate please ?
Flags: needinfo?(aklotz)
Crash Signature: [@ <T>::operator() | mozilla::detail::RunnableFunction<T>::Run] [@ CoMarshalInterface ] [@ CDestObjectWrapper::MarshalInterface ] → [@ <T>::operator() | mozilla::detail::RunnableFunction<T>::Run] [@ RefPtr<T>::assign_assuming_AddRef | <T>::operator() | mozilla::detail::RunnableFunction<T>::Run] [@ CoMarshalInterface ] [@ CDestObjectWrapper::MarshalInterface ]
This... is odd. I see mozilla::a11y::HandlerProvider::put_HandlerControl being called with a non-null aCtrl interface... but its vtable is null!
Flags: needinfo?(aklotz)
(So the reason we're seeing this now is because of the handler being enabled by default)
Whiteboard: aes+
Almost entirely on 64-bit too...
I just ran into a crash like this while commenting on another bug. My report is bp-9f9383f1-9f61-4341-8955-605de0170622
Crash Signature: [@ <T>::operator() | mozilla::detail::RunnableFunction<T>::Run] [@ RefPtr<T>::assign_assuming_AddRef | <T>::operator() | mozilla::detail::RunnableFunction<T>::Run] [@ CoMarshalInterface ] [@ CDestObjectWrapper::MarshalInterface ] → [@ <T>::operator() | mozilla::detail::RunnableFunction<T>::Run] [@ RefPtr<T>::assign_assuming_AddRef | <T>::operator() | mozilla::detail::RunnableFunction<T>::Run] [@ CoMarshalInterface ] [@ CDestObjectWrapper::MarshalInterface ] [@ @0x0 | CoMarshalIn…
Crash Signature: CoMarshalInterface ] → CoMarshalInterface ] [@ gfxDWriteFont::CopyWithAntialiasOption ] [@ combase.dll@0x29b39 ] [@ nsCOMPtr_base::~nsCOMPtr_base | mozilla::mscom::EnsureMTA::EnsureMTA<T> ]
Crash Signature: CoMarshalInterface ] [@ gfxDWriteFont::CopyWithAntialiasOption ] [@ combase.dll@0x29b39 ] [@ nsCOMPtr_base::~nsCOMPtr_base | mozilla::mscom::EnsureMTA::EnsureMTA<T> ] → CoMarshalInterface ] [@ gfxDWriteFont::CopyWithAntialiasOption ] [@ combase.dll@0x29b39 ] [@ nsCOMPtr_base::~nsCOMPtr_base | mozilla::mscom::EnsureMTA::EnsureMTA<T> ] [@ RtlpWaitOnCriticalSection | RtlpEnterCriticalSectionContended | RtlEnterCritical…
Bug 1374792 is also dealing with null / corrupt vtables. I think they are different signatures of the same root cause.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.