Summary: | CrashTracer beneath JSC::MarkedBlock::specializedSweep | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Geoffrey Garen <ggaren> | ||||
Component: | New Bugs | Assignee: | Geoffrey Garen <ggaren> | ||||
Status: | RESOLVED FIXED | ||||||
Severity: | Normal | CC: | cdumez, commit-queue, eric.carlson, esprehn+autocc, gyuyoung.kim, jer.noble, saam | ||||
Priority: | P2 | ||||||
Version: | WebKit Nightly Build | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Attachments: |
|
Description
Geoffrey Garen
2016-06-28 13:27:41 PDT
Created attachment 282278 [details]
Patch
Comment on attachment 282278 [details]
Patch
LGTM
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. 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? (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())". > 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.
Committed r202590: <http://trac.webkit.org/changeset/202590> |