Closed Bug 1204663 Opened 9 years ago Closed 9 years ago

Sage Academy courses crash the content process with async plugin init enabled

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
Unspecified
Windows
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox41 wontfix, firefox42+ fixed, firefox43+ fixed)

Status:
RESOLVED DUPLICATE of bug 1209464
Tracking Flags:
Tracking Status
firefox41 --- wontfix
firefox42 + fixed
firefox43 + fixed

People

(Reporter: RyanVM, Assigned: bugzilla)

References

Details

(Keywords: crash)

Crash Data

Looks like they use Flash to load all the courses. I can confirm that I get no crashes with async init disabled and insta-crash of the entire content process with it enabled.

This bug report came to me from a family member currently on beta, so it affects 41+. Forwarding the STR to aklotz now via email since it's a restricted site behind a login.
Tracking for 42+, sounds good that we have exact STR. 
Aaron have you got this bug? I am not sure which bug exactly to make it dependent on for async init.
tracking-firefox42: ? → +
tracking-firefox43: ? → +
Flags: needinfo?(aklotz)
I'm going to diagnose it, yes. Once I have more info I'll set the dependency if necessary.
Assignee: nobody → aklotz
Flags: needinfo?(aklotz)
Crash Signature: [@ hang | RtlEnterCriticalSection | arena_malloc_small | imalloc | je_realloc | std::_Deque_const_iterator<T>::_Deque_const_iterator<T>(std::_Deque_const_iterator<T> const&) ] [@ hang | WaitForMultipleObjectsEx | MsgWaitForMultipleObjectsEx | MsgWaitForM…
Keywords: crash
I'm having trouble reproducing this. Can you see if this is still an issue on 42 beta 5 when it is released? There are some other plugin patches in that one that probably affect this.
Flags: needinfo?(ryanvm)
I'm also unable to reproduce the crash on 42b5.

However, I can still reproduce on today's m-c nightly with async plugin init forced on, but only on the first load of the page. After that, it appears to work w/o issue on subsequent attempts. Looking at Task Manager, it appears that plugin-container is still running after the crash, so presumably it works the second time around because of that. If I force kill plugin-container, it crashes again.
https://crash-stats.mozilla.com/report/index/c52bc9f2-5438-4e98-a4e1-9379e2151012
Flags: needinfo?(ryanvm)
Does *not* crash on Nightly w/ e10s disabled.
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #5)
> I'm also unable to reproduce the crash on 42b5.
> 
> However, I can still reproduce on today's m-c nightly with async plugin init
> forced on, but only on the first load of the page. After that, it appears to
> work w/o issue on subsequent attempts. Looking at Task Manager, it appears
> that plugin-container is still running after the crash, so presumably it
> works the second time around because of that. If I force kill
> plugin-container, it crashes again.
> https://crash-stats.mozilla.com/report/index/c52bc9f2-5438-4e98-a4e1-
> 9379e2151012

That crash is bug 1213454.
Crash Signature: MsgWaitForMultipleObjects | F_1152915508___________________________________ ] → MsgWaitForMultipleObjects | F_1152915508___________________________________ ] [@ hang | RtlEnterCriticalSection | arena_malloc_small | imalloc | je_realloc | std::_Deque_const_iterator<T>::_Deque_const_iterator<T> ]
(In reply to Aaron Klotz [:aklotz] (please use needinfo) from comment #7)
> That crash is bug 1213454.

No crashes with that patch applied locally :)
Cool. I'm going to mark this one as a dupe of bug 1209464 and I'll be sure to uplift bug 1213454 to beta.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.