RESOLVED FIXED 159223
CrashTracer beneath JSC::MarkedBlock::specializedSweep 
https://bugs.webkit.org/show_bug.cgi?id=159223
Summary CrashTracer beneath JSC::MarkedBlock::specializedSweep
Geoffrey Garen
Reported 2016-06-28 13:27:41 PDT
CrashTracer beneath JSC::MarkedBlock::specializedSweep
Attachments
Patch (3.61 KB, patch)
2016-06-28 13:32 PDT, Geoffrey Garen 		saam: review+
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Geoffrey Garen
Comment 1 2016-06-28 13:32:13 PDT
Created attachment 282278 [details] Patch
Saam Barati
Comment 2 2016-06-28 14:00:48 PDT
Comment on attachment 282278 [details] Patch LGTM
Saam Barati
Comment 3 2016-06-28 14:01:22 PDT
Also, maybe you can add an assertion that doesn't allow VM entry when a GC is happening? That might help us find other bugs.
Saam Barati
Comment 4 2016-06-28 14:01:52 PDT
Comment on attachment 282278 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=282278&action=review > Source/WebCore/ChangeLog:13 > + In theory, other CachedResourceClients in the DOM might also trigger > + similar bugs, but our data only implicates the media elements, so this > + fix targets them. Should we open a bug for other CachedResourceClients to vet their correctness?
Geoffrey Garen
Comment 5 2016-06-28 14:33:46 PDT
(In reply to comment #3) > Also, maybe you can add an assertion that doesn't allow VM entry when a GC > is happening? That might help us find other bugs. MarkedAllocator::tryAllocate does "ASSERT(!m_heap->isBusy())".
Geoffrey Garen
Comment 6 2016-06-28 14:34:28 PDT
> Should we open a bug for other CachedResourceClients to vet their > correctness? It really wasn't clear to me from looking whether they're OK or not OK. I think we should wait for data -- and perhaps consider whether we can make re-entering JS during a destructor safe.
Geoffrey Garen
Comment 7 2016-06-28 14:35:57 PDT
Committed r202590: <http://trac.webkit.org/changeset/202590>
Note You need to log in before you can comment on or make changes to this bug.