Closed Bug 1065881 Opened 10 years ago Closed 10 years ago

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

Categories

(Core :: Graphics, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla36
Tracking Status
e10s m4+ ---

People

(Reporter: markh, Assigned: handyman)

References

(Blocks 1 open bug)

Details

(Keywords: crash)

Attachments

(1 file)

+++ 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: e10s-addons
tracking-e10s: --- → +
Blocks: e10s-tests
Keywords: crash
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.
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)
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.
Attachment #8504292 - Flags: review?(nical.bugzilla) → review+
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/96aefa302688
Status: NEW → RESOLVED
Closed: 10 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
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
You need to log in before you can comment on or make changes to this bug.