Changeset 211347 in webkit
- Timestamp:
- Jan 28, 2017 11:15:33 PM (7 years ago)
- Location:
- trunk/Source/WebKit2
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/Source/WebKit2/ChangeLog
r211346 r211347 1 2017-01-28 Carlos Garcia Campos <cgarcia@igalia.com> 2 3 [Threaded Compositor] Crash when deleting the compositor run loop 4 https://bugs.webkit.org/show_bug.cgi?id=167545 5 6 Reviewed by Michael Catanzaro. 7 8 The problem is that we are releasing the WorkQueue before the update timer that keeps a reference to the run 9 loop, destroyed by the WorkQueue. So, invalidate the WorkQueue in the next run loop iteration to ensure it 10 happens after the CompositingRunLoop destructor. 11 12 * Shared/CoordinatedGraphics/threadedcompositor/CompositingRunLoop.cpp: 13 (WebKit::CompositingRunLoop::~CompositingRunLoop): 14 1 15 2017-01-28 Carlos Garcia Campos <cgarcia@igalia.com> 2 16 -
trunk/Source/WebKit2/Shared/CoordinatedGraphics/threadedcompositor/CompositingRunLoop.cpp
r205484 r211347 120 120 CompositingRunLoop::~CompositingRunLoop() 121 121 { 122 WorkQueuePool::singleton().invalidate(this); 122 ASSERT(isMainThread()); 123 // Make sure the WorkQueue is deleted after the CompositingRunLoop, because m_updateTimer has a reference 124 // of the WorkQueue run loop. Passing this is not a problem because the pointer will only be used as a 125 // HashMap key by WorkQueuePool. 126 RunLoop::main().dispatch([context = this] { WorkQueuePool::singleton().invalidate(context); }); 123 127 } 124 128
Note: See TracChangeset
for help on using the changeset viewer.