Bug 207938 – [ Mac wk2 ] http/wpt/crypto/derive-hmac-key-crash.any.html is flaky crashing

• Component: Page Loading
• Status: RESOLVED DUPLICATE

[Jason Lawrence]

http/wpt/crypto/derive-hmac-key-crash.any.html


Description:
This test is flaky crashing on Mac wk2. The crashes appear to have started at r256842.


History:
https://results.webkit.org/?suite=layout-tests&test=http%2Fwpt%2Fcrypto%2Fderive-hmac-key-crash.any.html&flavor=wk2&platform=mac

Crash log:
https://build.webkit.org/results/Apple-Catalina-Debug-WK2-Tests/r256916%20(2407)/http/wpt/crypto/derive-hmac-key-crash.any-crash-log.txt

[Jason Lawrence]

Created attachment 391164 [details]
Crash Log

[Radar WebKit Bug Importer]

<rdar://problem/59591165>

[Jason Lawrence]

I have marked this test as crashing while this issue is investigated.
https://trac.webkit.org/changeset/256919/webkit

[Jason Lawrence]

I am able to reproduce this with a debug build of r256941 by running the command below.
run-webkit-tests http/wpt/crypto/derive-hmac-key-crash.any.html --iterations 4000 --exit-after-n-failures 5 -f --force --debug -g

[252/4000] http/wpt/crypto/derive-hmac-key-crash.any.html failed unexpectedly (com.apple.WebKit.WebContent.Development crashed [pid=48111])
[256/4000] http/wpt/crypto/derive-hmac-key-crash.any.html failed unexpectedly (com.apple.WebKit.WebContent.Development crashed [pid=48117])
[263/4000] http/wpt/crypto/derive-hmac-key-crash.any.html failed unexpectedly (com.apple.WebKit.WebContent.Development crashed [pid=48113])
[378/4000] http/wpt/crypto/derive-hmac-key-crash.any.html failed unexpectedly (com.apple.WebKit.WebContent.Development crashed [pid=48115])
[386/4000] http/wpt/crypto/derive-hmac-key-crash.any.html failed unexpectedly (com.apple.WebKit.WebContent.Development crashed [pid=48119])
Python[48078]: unlink: 'observations.db-wal' guarded by com.apple.WebKit[48205] (0x8fd4dbfade2dead)
Exiting early after 5 failures. 381 tests run.

376 tests ran as expected, 5 didn't (3619 didn't run):

[Alexey Proskuryakov]

SHOULD NEVER BE REACHED
/Volumes/Data/slave/catalina-debug/build/Source/WebKit/NetworkProcess/Classifier/ResourceLoadStatisticsDatabaseStore.cpp(952) : unsigned int WebKit::ResourceLoadStatisticsDatabaseStore::getNumberOfPrevalentResources() const
1   0x13186bd79 WTFCrash
2   0x10d31046b WTFCrashWithInfo(int, char const*, char const*, int)
3   0x10d9aa2ec WebKit::ResourceLoadStatisticsDatabaseStore::getNumberOfPrevalentResources() const
4   0x10d9aaac0 WebKit::ResourceLoadStatisticsDatabaseStore::calculateTelemetryData(WebKit::PrevalentResourceDatabaseTelemetry&) const
5   0x10d9ab713 WebKit::ResourceLoadStatisticsDatabaseStore::calculateAndSubmitTelemetry() const
6   0x10d9d5e17 WebKit::ResourceLoadStatisticsDatabaseStore::ResourceLoadStatisticsDatabaseStore(WebKit::WebResourceLoadStatisticsStore&, WTF::WorkQueue&, WebKit::ShouldIncludeLocalhost, WTF::String const&, PAL::SessionID)::$_11::operator()() const
7   0x10d9d5cf9 WTF::Detail::CallableWrapper<WebKit::ResourceLoadStatisticsDatabaseStore::ResourceLoadStatisticsDatabaseStore(WebKit::WebResourceLoadStatisticsStore&, WTF::WorkQueue&, WebKit::ShouldIncludeLocalhost, WTF::String const&, PAL::SessionID)::$_11, void>::call()
8   0x1318963aa WTF::Function<void ()>::operator()() const

[Alexey Proskuryakov]

This is the same issue as bug 207269, just moved to a new place.

I've been unable to extract the log message from any bots. But I have logging from Kate's machine that says this:

ResourceLoadStatisticsDatabaseStore::getNumberOfPrevalentResources failed to step, error message: another row available

[Kate Cheney]

(In reply to Alexey Proskuryakov from comment #6)
> This is the same issue as bug 207269, just moved to a new place.
> 
> I've been unable to extract the log message from any bots. But I have
> logging from Kate's machine that says this:
> 
> ResourceLoadStatisticsDatabaseStore::getNumberOfPrevalentResources failed to
> step, error message: another row available

Hmm, this error message doesn't seem to align with where this crash is happening, because another row available means the result value was SQLITE_ROW, which is not the case if the execution enters this block. I wonder if the return value is not SQLITE_ROW or SQLITE_DONE but doesn't return an error. Investigating this now.

[Kate Cheney]

*** This bug has been marked as a duplicate of bug 208206 ***