Bug 181546 – WKWebView.ClearAppCache is a flaky API test failure on High Sierra.

• Component: New Bugs
• Status: RESOLVED FIXED

[Matt Lewis]

WKWebView.ClearAppCache is a flaky API failure on High Sierra.

build:
https://build.webkit.org/builders/Apple%20High%20Sierra%20Release%20WK1%20(Tests)/builds/2565/steps/run-api-tests/logs/stdio
https://build.webkit.org/builders/Apple%20High%20Sierra%20Release%20WK1%20(Tests)/builds/2565

Error in log:

FAIL WKWebView.ClearAppCache

/Volumes/Data/slave/highsierra-release/build/Tools/TestWebKitAPI/Tests/WebKitCocoa/LocalStorageClear.mm:183
Value of: 1ul
  Actual: 1
Expected: websiteDataRecords.count
Which is: 2


/Volumes/Data/slave/highsierra-release/build/Tools/TestWebKitAPI/Tests/WebKitCocoa/LocalStorageClear.mm:185
Value of: [record.displayName UTF8String]
  Actual: "Local documents on your computer"
Expected: "127.0.0.1"


/Volumes/Data/slave/highsierra-release/build/Tools/TestWebKitAPI/Tests/WebKitCocoa/LocalStorageClear.mm:187
Value of: [type UTF8String]
  Actual: "WKWebsiteDataTypeLocalStorage"
Expected: [WKWebsiteDataTypeOfflineWebApplicationCache UTF8String]
Which is: "WKWebsiteDataTypeOfflineWebApplicationCache"


I was able to reproduce the failure locally by running this twice:
run-api-tests --debug WKWebView --verbose

The crash claimed it to be a simulated crash.

[Radar WebKit Bug Importer]

<rdar://problem/36444327>

[Alexey Proskuryakov]

I believe that we've been seeing it very frequently on El Capitan as well.

[Chris Dumez]

(In reply to Alexey Proskuryakov from comment #2)
> I believe that we've been seeing it very frequently on El Capitan as well.

The type of data that remains is localStorage. It remains after the initial call to remove all data :/

[Chris Dumez]

LocalStorageDatabaseTracker::deleteDatabasesModifiedSince() chooses not to delete file__0 because it is not able to compute the last modified time for path:
/Users/chris/Library/WebKit/TestWebKitAPI/WebsiteData/LocalStorage/file__0.localstorage

[Chris Dumez]

(In reply to Chris Dumez from comment #4)
> LocalStorageDatabaseTracker::deleteDatabasesModifiedSince() chooses not to
> delete file__0 because it is not able to compute the last modified time for
> path:
> /Users/chris/Library/WebKit/TestWebKitAPI/WebsiteData/LocalStorage/file__0.
> localstorage

/Users/chris/Library/WebKit/TestWebKitAPI/WebsiteData/LocalStorage/file__0.localstorage
does not exist on my machine but I have /Users/chris/Library/WebKit/TestWebKitAPI/WebsiteData/LocalStorage/file__0.localstorage-wal !

[Chris Dumez]

I suspect it could be related to LocalStorageDatabaseTracker::deleteAllDatabases() using FileSystem::deleteFile() instead of SQLiteFileSystem::deleteDatabaseFile().

[Chris Dumez]

(In reply to Chris Dumez from comment #6)
> I suspect it could be related to
> LocalStorageDatabaseTracker::deleteAllDatabases() using
> FileSystem::deleteFile() instead of SQLiteFileSystem::deleteDatabaseFile().

Not it, LocalStorageDatabaseTracker::deleteAllDatabases() appears to be unused.

[Chris Dumez]

Looks like we correctly use SQLiteFileSystem::deleteDatabaseFile() in all places. So I suspect the issue could be that we are deleting database files while the database is still open. I guess Sqlite could end up later writing a -wal file as a result.

[Chris Dumez]

e.g. LocalStorageDatabaseTracker::removeDatabaseWithOriginIdentifier() seems to delete the database file while it is open.

[Chris Dumez]

Created attachment 336082 [details]
Patch

[WebKit Commit Bot]

Comment on attachment 336082 [details]
Patch

Clearing flags on attachment: 336082

Committed r229736: <https://trac.webkit.org/changeset/229736>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.