WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
47873
iOS: ASSERT in Cache::adjustSize running layout tests
https://bugs.webkit.org/show_bug.cgi?id=47873
Summary
iOS: ASSERT in Cache::adjustSize running layout tests
Joseph Pecoraro
Reported
2010-10-18 19:37:51 PDT
<
rdar://problem/8470328
> ASSERTION FAILED: delta >= 0 || ((int)m_deadSize + delta >= 0) in WebCore/loader/Cache.cpp:686 void WebCore::Cache::adjustSize(bool, int) iOS has Cache::shouldMakeResourcePurgeableOnEviction returning true, and is seeing the following ASSERT running LayoutTests: Thread 0 Crashed: Dispatch queue: com.apple.main-thread 0 WebCore 0x01122c09 WebCore::Cache::adjustSize(bool, int) + 201 (Cache.cpp:686) 1 WebCore 0x01123c1a WebCore::Cache::makeResourcePurgeable(WebCore::CachedResource*) + 168 (Cache.cpp:436) 2 WebCore 0x01123fc4 WebCore::Cache::pruneDeadResources() + 922 (Cache.cpp:384) 3 WebCore 0x0112961b WebCore::Cache::prune() + 85 (Cache.h:142) The ASSERT is: ASSERT(delta >= 0 || ((int)m_deadSize + delta >= 0)); It appears as though resources are removing themselves (via adjustSize) multiple times when pruning dead resources. The "makeResourcePurgeable" performs an adjustSize on an already purgeable resource. (gdb) b WebCore::Cache::adjustSize Breakpoint 1 at 0x1336717: file WebCore/loader/Cache.cpp, line 684. (gdb) commands Type commands for when breakpoint 1 is hit, one per line. End with a line saying just "end". > bt 10 > c > end Breakpoint 1, WebCore::Cache::adjustSize (this=0x881a000, live=false, delta=-45470) at WebCore/loader/Cache.cpp:684 684 if (live) { #0 WebCore::Cache::adjustSize (this=0x881a000, live=false, delta=-45470) at WebCore/loader/Cache.cpp:684 #1 0x013377f6 in WebCore::Cache::makeResourcePurgeable (this=0x881a000, resource=0x103bd800) at WebCore/loader/Cache.cpp:435 #2 0x01337ba0 in WebCore::Cache::pruneDeadResources (this=0x881a000) at WebCore/loader/Cache.cpp:385 #3 0x0133d207 in WebCore::Cache::prune (this=0x881a000) at Cache.h:141 #4 0x01338092 in WebCore::Cache::setCapacities (this=0x881a000, minDeadBytes=0, maxDeadBytes=0, totalBytes=4194304) at WebCore/loader/Cache.cpp:418 #5 0x0573b754 in +[WebView(WebFileInternal) _setCacheModel:] (self=0x57ea814, _cmd=0x57582e0, cacheModel=0) at WebKit/mac/WebView/WebView.mm:6537 #6 0x0573ae23 in +[WebView(WebFileInternal) _preferencesChangedNotification:] (self=0x57ea814, _cmd=0x57904cb, notification=0x11852240) at WebKit/mac/WebView/WebView.mm:6584 #7 0x007286c1 in _nsnote_callback () #8 0x00302f99 in __CFXNotificationPost_old () #9 0x0028233a in _CFXNotificationPostNotification () ... a little later ... without it showing up in between ... Breakpoint 1, WebCore::Cache::adjustSize (this=0x881a000, live=false, delta=-45470) at WebCore/loader/Cache.cpp:684 684 if (live) { #0 WebCore::Cache::adjustSize (this=0x881a000, live=false, delta=-45470) at WebCore/loader/Cache.cpp:684 #1 0x013377f6 in WebCore::Cache::makeResourcePurgeable (this=0x881a000, resource=0x103bd800) at WebCore/loader/Cache.cpp:435 #2 0x01337ba0 in WebCore::Cache::pruneDeadResources (this=0x881a000) at WebCore/loader/Cache.cpp:385 #3 0x0133d207 in WebCore::Cache::prune (this=0x881a000) at Cache.h:141 #4 0x01345c0f in WebCore::CachedResource::removeClient (this=0x118710b0, client=0x11872bf4) at WebCore/loader/CachedResource.cpp:210 #5 0x01d142a5 in WebCore::ScriptElementData::execute (this=0x11872bf4, cachedScript=0x118710b0) at WebCore/dom/ScriptElement.cpp:207 #6 0x014d7505 in WebCore::Document::executeScriptSoonTimerFired (this=0x834ec00, timer=0x834f21c) at WebCore/dom/Document.cpp:4966 #7 0x014f72e9 in WebCore::Timer<WebCore::Document>::fired (this=0x834f21c) at Timer.h:102 #8 0x01e988c6 in WebCore::ThreadTimers::sharedTimerFiredInternal (this=0x902ea50) at WebCore/platform/ThreadTimers.cpp:126 #9 0x01e9897d in WebCore::ThreadTimers::sharedTimerFired () at WebCore/platform/ThreadTimers.cpp:101 Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xbbadbeef 0x013367cd in WebCore::Cache::adjustSize (this=0x881a000, live=false, delta=-45470) at WebCore/loader/Cache.cpp:688 688 ASSERT(delta >= 0 || ((int)m_deadSize + delta >= 0));
Attachments
[PATCH] Proposed Change
(2.51 KB, patch)
2010-10-18 19:46 PDT
,
Joseph Pecoraro
no flags
Details
Formatted Diff
Diff
[PATCH] Return True and Keep Purgeable Resource in the Lists
(2.50 KB, patch)
2010-10-19 10:54 PDT
,
Joseph Pecoraro
ddkilzer
: review+
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Joseph Pecoraro
Comment 1
2010-10-18 19:46:14 PDT
Created
attachment 71120
[details]
[PATCH] Proposed Change I'll be rebasing and re-running test to verify. If desired I may be able to make a test for this: - Cache a resource - Loop and continually prune the cache enough that it would likely underflow (m_deadSize is unsigned and underflowing triggers the ASSERT) - Have the test pass if there was no assertion. Another approach might be to add a method to Cache to verify its integrity. This might be worth doing, so let me know!
Joseph Pecoraro
Comment 2
2010-10-19 09:36:17 PDT
Actually, I think I can (and should) return "true" here. That way it would not get evicted the second pass through the pruneDeadResources list and instead stay in the lists with its "purgeable" but "not purged" state. It would eventually get evicted if it ever "wasPurged()" in an code block inside of pruning.
Joseph Pecoraro
Comment 3
2010-10-19 10:54:31 PDT
Created
attachment 71185
[details]
[PATCH] Return True and Keep Purgeable Resource in the Lists
David Kilzer (:ddkilzer)
Comment 4
2010-10-19 12:39:23 PDT
Comment on
attachment 71185
[details]
[PATCH] Return True and Keep Purgeable Resource in the Lists r=me
Joseph Pecoraro
Comment 5
2010-10-19 13:35:37 PDT
Thanks! Committed
r70077
M WebCore/ChangeLog M WebCore/loader/Cache.cpp
r70077
= 4fb7c2de4c7e231e9a2ade392063bffe48002ab7
http://trac.webkit.org/changeset/70077
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug