Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: ef9aeb1646ff1bee0cd2b12460f83bace3f9ebd7
https://github.com/WebKit/WebKit/commit/ef9aeb1646ff1bee0cd2b12460f83bace3f9ebd7
Author: Chris Dumez <[email protected]>
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
_______________________________________________
webkit-changes mailing list
[email protected]
https://lists.webkit.org/mailman/listinfo/webkit-changes
