[webkit-changes] [WebKit/WebKit] ef9aeb: RELEASE_ASSERT(!resources.get(key)) hit in MemoryC...
Chris Dumez
noreply at github.com
Wed Jul 19 16:51:27 PDT 2023
Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: ef9aeb1646ff1bee0cd2b12460f83bace3f9ebd7
https://github.com/WebKit/WebKit/commit/ef9aeb1646ff1bee0cd2b12460f83bace3f9ebd7
Author: Chris Dumez <cdumez at apple.com>
Date: 2023-07-19 (Wed, 19 Jul 2023)
Changed paths:
A LayoutTests/http/tests/workers/memory-cache-crash-expected.txt
A LayoutTests/http/tests/workers/memory-cache-crash.html
M Source/WebCore/loader/cache/CachedResource.cpp
M Source/WebCore/loader/cache/CachedResource.h
M Source/WebCore/loader/cache/MemoryCache.cpp
Log Message:
-----------
RELEASE_ASSERT(!resources.get(key)) hit in MemoryCache::revalidationSucceeded()
https://bugs.webkit.org/show_bug.cgi?id=259339
rdar://112526836
Reviewed by Brent Fulgham.
When a resource needs network revalidation, we remove it from the memory cache,
add a "proxy" resource in the cache instead. Because revalidation happens
asynchronously, it is possible that another caller adds a resource back in the
cache with the same key (because they loaded the same URL). If this happened,
we'd overwrite the existing resource MemoryCache::revalidationSucceeded(),
leaving this resource and the memory cache in a bad state. The resource would
still think it is in the cache and may remain in some containers (e.g. LRUList)
inside the memory cache.
To address the issue, upon successful revalidation, we now check if there is
already a resource with the same key in the cache. If there is such resource,
we ignore the revalidated resource and transfer the clients from the revalidation
resource to the resource that already exists in the cache.
* LayoutTests/http/tests/workers/memory-cache-crash-expected.txt: Added.
* LayoutTests/http/tests/workers/memory-cache-crash.html: Added.
* Source/WebCore/loader/cache/MemoryCache.cpp:
(WebCore::MemoryCache::revalidationSucceeded):
Canonical link: https://commits.webkit.org/266170@main
More information about the webkit-changes
mailing list