158646 2016-06-10 17:10:37 -0700 [Yosemite Release WK2] imported/w3c/IndexedDB-private-browsing/idbfactory_open9.html is a flaky timeout 2024-05-08 07:37:53 -0700 1 1 1 Unclassified WebKit New Bugs WebKit Nightly Build Unspecified Unspecified RESOLVED CONFIGURATION CHANGED https://bugs.webkit.org/show_bug.cgi?id=159827 P2 Normal --- 154968 1 ryanhaddad webkit-unassigned ahmad.saleem792 ap beidson jbedard oldest_to_newest 1201445 0 ryanhaddad 2016-06-10 17:10:37 -0700 imported/w3c/IndexedDB-private-browsing/idbfactory_open9.html is a flaky timeout <https://build.webkit.org/builders/Apple%20Yosemite%20Release%20WK2%20(Tests)/builds/15220> <https://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=imported%2Fw3c%2FIndexedDB-private-browsing%2Fidbfactory_open9.html> 1201446 1 ryanhaddad 2016-06-10 17:10:58 -0700 Seems to time out alongside imported/w3c/IndexedDB-private-browsing/idbfactory_open9.html 1201447 2 ryanhaddad 2016-06-10 17:11:49 -0700 (In reply to comment #1) > Seems to time out alongside > imported/w3c/IndexedDB-private-browsing/idbfactory_open9.html By that, I meant imported/blink/storage/indexeddb/blob-delete-objectstore-db.html 1201656 3 ap 2016-06-11 16:19:49 -0700 I wonder if these timeouts are misreported crashes, like in bug 158665. 1201673 4 beidson 2016-06-11 17:57:16 -0700 (In reply to comment #3) > I wonder if these timeouts are misreported crashes, like in bug 158665. I would love a conclusion on that, as some of these IDB timeouts are beyond mysterious - How do we find out for sure? 1201681 5 ap 2016-06-11 21:41:55 -0700 I checked the bot where the build quoted by Ryan took place, and there is no crash stored there that would be relevant. So chances are that it's a true timeout. Perhaps we could temporarily enable sampling on timeout, or even take a spindump. I'd r+ a patch for that. 1201686 6 beidson 2016-06-11 21:45:13 -0700 (In reply to comment #5) > I checked the bot where the build quoted by Ryan took place, and there is no > crash stored there that would be relevant. So chances are that it's a true > timeout. > > Perhaps we could temporarily enable sampling on timeout, or even take a > spindump. I'd r+ a patch for that. I would r+ one, too, but I certainly don't know how to implement one myself. 1201688 7 ap 2016-06-11 22:01:38 -0700 Whoops, this timeout in particular is not a freeze (at least not in WebKitTestRunner or WebContent). It has output: https://build.webkit.org/results/Apple%20Yosemite%20Release%20WK2%20(Tests)/r201935%20(15220)/imported/w3c/IndexedDB-private-browsing/idbfactory_open9-pretty-diff.html Enabling sample on WKTR is easy (we'd just need to remove --no-sample from arguments), but this is a Databases process freeze at best, and more likely not a freeze at all. 1207741 8 beidson 2016-07-04 21:44:57 -0700 (In reply to comment #7) > Whoops, this timeout in particular is not a freeze (at least not in > WebKitTestRunner or WebContent). It has output: > https://build.webkit.org/results/Apple%20Yosemite%20Release%20WK2%20(Tests)/ > r201935%20(15220)/imported/w3c/IndexedDB-private-browsing/idbfactory_open9- > pretty-diff.html > > Enabling sample on WKTR is easy (we'd just need to remove --no-sample from > arguments), but this is a Databases process freeze at best, and more likely > not a freeze at all. Confirming, this cannot be a database process freeze (or crash, or hang), because this is a private browsing test: Database process is not involved at all. 2033996 9 ahmad.saleem792 2024-05-08 07:37:53 -0700 It seems that we don't have any timeout since I couldn't find any platform specific expectations by looking into 'searchfox.org' on wubkat index with 'IndexedDB-private-browsing/idbfactory_open9' keyword and only results (test and expectation file). Marking this as 'RESOLVED CONFIGURATION CHANGED'.