Bug 39183 – REGRESSION(sometime before r59554): fast/workers/storage/execute-sql-args-worker.html crashes occasionally on Gtk Bot

• Component: Tools / Tests
• Status: RESOLVED WORKSFORME

[Eric Seidel (no email)]

fast/workers/storage/execute-sql-args-worker.html crashes occasionally on Gtk Bot

It's hitting an ASSERT:
ASSERTION FAILED: !protectedObjectCount()
(../../JavaScriptCore/runtime/Collector.cpp:323 void JSC::Heap::freeBlocks())

http://build.webkit.org/results/GTK%20Linux%2064-bit%20Debug/r59577%20(5945)/fast/workers/storage/execute-sql-args-worker-stderr.txt

I believe it's been crashing longer than we have /console data for.  However the oldest crash I currently see on the /console is r59554.  The crash occurs quite often.

[Eric Seidel (no email)]

One victim of this false positive:
https://bugs.webkit.org/show_bug.cgi?id=39179#c5

[Eric Seidel (no email)]

Oliver added this ASSERT as part of http://trac.webkit.org/changeset/53460 (4 months ago).  Perhaps he has some clue how it might be firing for workers in this test?

I haven't yet dug back through the results to see the first ever time this failed.  I suspect it's been around for less than a week.

[Dmitry Titov]

One theory could be that there are indeed non-released protected objects when the worker thread is terminating and JSC does the final GC.

Database layer uses quite a lot of ProtectedPtrs to keep the callbacks for async SQLTransactions alive until they need to be fired. The first look at code says we release them all before the WorkerThread terminates, but there might be more to the picture.

[Eric Seidel (no email)]

Unfortunately webkit doesn't yet have any tools to easily tell us when this started.  However this is now ridiculously common and is causing all sorts of sheriff-bot spam and commit-queue blockage. :(

[Xan Lopez]

(In reply to comment #4)
> Unfortunately webkit doesn't yet have any tools to easily tell us when this started.  However this is now ridiculously common and is causing all sorts of sheriff-bot spam and commit-queue blockage. :(

Can we just skip this for now? Can't do it atm, so if someone can just go ahead... otherwise I'll do it in the (my) morning.

[Eric U.]

(In reply to comment #4)
> Unfortunately webkit doesn't yet have any tools to easily tell us when this started.  However this is now ridiculously common and is causing all sorts of sheriff-bot spam and commit-queue blockage. :(

It's a new test; it only went in this weekend, in my http://trac.webkit.org/changeset/59540.  We had a similar breakage the previous try submitting it; since nobody could reproduce it locally, we put it in to see if it would still crash.  It did, we found a bug that would cause that problem, fixed it, and submitted again.

Clearly there's still a problem left.  However, I see that https://bugs.webkit.org/show_bug.cgi?id=30814 disabled all other storage tests for GTK due to mysterious threading problems.  Perhaps GTK and storage still just don't mix?

I'm going to try to repro this again, but last time I tried, it all ran just fine.

[Eric U.]

(In reply to comment #6)
> (In reply to comment #4)
> > Unfortunately webkit doesn't yet have any tools to easily tell us when this started.  However this is now ridiculously common and is causing all sorts of sheriff-bot spam and commit-queue blockage. :(
> 
> It's a new test; it only went in this weekend, in my http://trac.webkit.org/changeset/59540.  We had a similar breakage the previous try submitting it; since nobody could reproduce it locally, we put it in to see if it would still crash.  It did, we found a bug that would cause that problem, fixed it, and submitted again.
> 
> Clearly there's still a problem left.  However, I see that https://bugs.webkit.org/show_bug.cgi?id=30814 disabled all other storage tests for GTK due to mysterious threading problems.  Perhaps GTK and storage still just don't mix?
> 
> I'm going to try to repro this again, but last time I tried, it all ran just fine.

I managed to get a local repro [on the order of one crash in 100 iterations when running run-webkit-tests --repeat 1000].  I'll track this down today.

[Eric Seidel (no email)]

I think this is the last bug blocking the commit queue (which is up to 20 patches). :(

Latest failure:
http://build.webkit.org/results/GTK%20Linux%2064-bit%20Debug/r59747%20(6147)/fast/workers/storage/execute-sql-args-worker-stderr.txt

[Eric Seidel (no email)]

Looks like this was skipped in bug 39346.  The bots are green for the moment.  :)

[Martin Robinson]

The test doesn't seem to be skipped any longer.