[e10s] Crash on child process shutdown in ShadowLayerForwarder::InWorkerThread

RESOLVED FIXED in mozilla36

Status

()

Core
Graphics
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: markh, Assigned: handyman)

Tracking

(Blocks: 1 bug, {crash})

Trunk
mozilla36
x86_64
Windows 7
crash
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10sm4+)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
+++ This bug was initially created as a clone of Bug #1041695 +++

Bug 1041695 fixed a crash running the test test_streams_element_capture.html, but it's still failing on Holly and can be reproduced in a local build.  The crash is now at child process shutdown and in the code added by bug 1041695:

bool
ShadowLayerForwarder::InWorkerThread()
{
  return GetMessageLoop()->id() == MessageLoop::current()->id();
}

MessageLoop::current() is returning null.  A quick hack to short-circuit that and return true when current() returns null then crashes in AssertWorkerThread in MessageChannel.h, which also calls MessageLoop::current().  Short-circuiting *that* then gets the test passing.  But I doubt that's correct :)

% mach mochitest-plain content/media/test/test_streams_element_capture.html --e10s

Stack:
>	xul.dll!MessageLoop::id()  Line 228 + 0xa bytes	C++
 	xul.dll!mozilla::layers::ShadowLayerForwarder::InWorkerThread()  Line 490 + 0x22 bytes	C++
 	xul.dll!mozilla::layers::ShadowLayerForwarder::RemoveTexture(mozilla::layers::TextureClient * aTexture)  Line 506 + 0x8 bytes	C++
 	xul.dll!mozilla::layers::TextureClient::Finalize()  Line 502	C++
 	xul.dll!mozilla::AtomicRefCountedWithFinalize<mozilla::layers::TextureClient>::Release()  Line 61	C++
 	xul.dll!mozilla::RefPtr<mozilla::layers::TextureClient>::unref(mozilla::layers::TextureClient * aVal)  Line 303	C++
 	xul.dll!mozilla::RefPtr<mozilla::layers::TextureClient>::~RefPtr<mozilla::layers::TextureClient>()  Line 242 + 0x12 bytes	C++
 	xul.dll!mozilla::layers::D3D9SurfaceImage::~D3D9SurfaceImage()  Line 20 + 0x25 bytes	C++
 	xul.dll!mozilla::layers::D3D9SurfaceImage::`scalar deleting destructor'()  + 0xf bytes	C++
 	xul.dll!mozilla::layers::Image::Release()  Line 144 + 0x9d bytes	C++
 	xul.dll!nsRefPtr<mozilla::layers::Image>::~nsRefPtr<mozilla::layers::Image>()  Line 854	C++
 	xul.dll!mozilla::VideoFrame::~VideoFrame()  Line 26 + 0xf bytes	C++
 	xul.dll!mozilla::VideoChunk::~VideoChunk()  Line 91 + 0x12 bytes	C++
 	xul.dll!mozilla::VideoChunk::`scalar deleting destructor'()  + 0xf bytes	C++
 	xul.dll!nsTArrayElementTraits<mozilla::VideoChunk>::Destruct(mozilla::VideoChunk * aE)  Line 486 + 0xd bytes	C++
 	xul.dll!nsTArray_Impl<mozilla::VideoChunk,nsTArrayInfallibleAllocator>::DestructRange(unsigned int aStart, unsigned int aCount)  Line 1642 + 0x9 bytes	C++
 	xul.dll!nsTArray_Impl<mozilla::VideoChunk,nsTArrayInfallibleAllocator>::RemoveElementsAt(unsigned int aStart, unsigned int aCount)  Line 1340	C++
 	xul.dll!mozilla::MediaSegmentBase<mozilla::VideoSegment,mozilla::VideoChunk>::RemoveLeading(__int64 aDuration, unsigned int aStartIndex)  Line 350	C++
 	xul.dll!mozilla::MediaSegmentBase<mozilla::VideoSegment,mozilla::VideoChunk>::ForgetUpTo(__int64 aDuration)  Line 170	C++
 	xul.dll!mozilla::StreamBuffer::Track::ForgetUpTo(__int64 aTime)  Line 156	C++
 	xul.dll!mozilla::StreamBuffer::ForgetUpTo(__int64 aTime)  Line 101	C++
 	xul.dll!mozilla::MediaStream::AdvanceTimeVaryingValuesToCurrentTime(__int64 aCurrentTime, __int64 aBlockedTime)  Line 567	C++
 	xul.dll!mozilla::MediaStreamGraphImpl::UpdateCurrentTimeForStreams(__int64 aPrevCurrentTime, __int64 aNextCurrentTime)  Line 399	C++
 	xul.dll!mozilla::MediaStreamGraphImpl::OneIteration(__int64 aFrom, __int64 aTo, __int64 aStateFrom, __int64 aStateEnd)  Line 1407	C++
 	xul.dll!mozilla::AudioCallbackDriver::DataCallback(float * aBuffer, long aFrames)  Line 828 + 0x37 bytes	C++
 	xul.dll!mozilla::AudioCallbackDriver::DataCallback_s(cubeb_stream * aStream, void * aUser, void * aBuffer, long aFrames)  Line 717	C++
 	gkmedias.dll!noop_resampler::fill(void * buffer, long frames_needed)  Line 89 + 0x1e bytes	C++
 	gkmedias.dll!cubeb_resampler_fill(cubeb_resampler * resampler, void * buffer, long frames_needed)  Line 245	C++
 	gkmedias.dll!`anonymous namespace'::refill(cubeb_stream * stm, float * data, long frames_needed)  Line 239 + 0x14 bytes	C++
 	gkmedias.dll!`anonymous namespace'::wasapi_stream_render_loop(void * stream)  Line 332 + 0x11 bytes	C++
 	msvcr100.dll!__endthreadex()  + 0x3a bytes	
 	msvcr100.dll!__endthreadex()  + 0xe4 bytes	
 	kernel32.dll!@BaseThreadInitThunk@12()  + 0x12 bytes	
 	ntdll.dll!___RtlUserThreadStart@8()  + 0x27 bytes	
 	ntdll.dll!__RtlUserThreadStart@8()  + 0x1b bytes
Assignee: nobody → davidp99
Blocks: 905436
tracking-e10s: --- → +
Blocks: 984139
tracking-e10s: + → m4+
Keywords: crash
(Reporter)

Comment 1

3 years ago
FTR, I disabled test_streams_element_capture.html under e10s on windows in bug 1072739 - it would be great if the patch for this bug can re-enable that test.
(Assignee)

Comment 2

3 years ago
Created attachment 8504292 [details] [diff] [review]
Allow non-message thread to dispatch to shadow worker thread

A minor fix...
This had caused a crash in the test_streams_element_capture mochitest on Windows.  The issue was that the audio decoder thread was destroying stale media frames by releasing a reference to them.  This was causing the release of an Image on that thread, but that thread does not process a MessageLoop so the current MessageLoop is null.  This is not a problem.  Obviously, any thread that has no MessageLoop can't be the worker thread.
Attachment #8504292 - Flags: review?(nical.bugzilla)
(Assignee)

Comment 3

3 years ago
Try build:
https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=58a45d9c64da

Also, this patch does enable (and pass) the test that markh mentioned in comment 1.

Updated

3 years ago
Attachment #8504292 - Flags: review?(nical.bugzilla) → review+
(Assignee)

Updated

3 years ago
Keywords: checkin-needed
https://hg.mozilla.org/integration/mozilla-inbound/rev/96aefa302688
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/96aefa302688
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Backed out under suspicion that it broke content process leak checking. I'm CCing mccr8 to this bug so you can discuss.
https://hg.mozilla.org/integration/mozilla-inbound/rev/f2409cd604c4
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: mozilla36 → ---
I relanded this because it seems like the failure showed up on the prior push as well.
   https://hg.mozilla.org/integration/mozilla-inbound/rev/450728938eb2
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
https://hg.mozilla.org/mozilla-central/rev/450728938eb2
You need to log in before you can comment on or make changes to this bug.