Ossy did some digging and found that at least recent crash reports from the Debug builders mention the IconDatabase in the worker crash logs.
fast/workers/worker-cloneport.html crash: http://www.sed.hu/webkit/qtbuildbot/results/x86-32%20Linux%20Qt%20Debug/r56065%20%281145%29/fast/workers/worker-cloneport-stderr.txt fast/workers/worker-close.html crash: http://www.sed.hu/webkit/qtbuildbot/results/x86-32%20Linux%20Qt%20Debug/r56065%20%281145%29/fast/workers/worker-close-stderr.txt Does that shed any light on the issue? -eric On Mon, Mar 29, 2010 at 6:32 PM, Drew Wilson <[email protected]> wrote: > Agreed, we (worker folks) should go investigate this further - it sounds > like we may be getting lucky and we have a platform that can repro the crash > more frequently. > I just wanted to mention that the main thing in the system that exercises > the platform-specific thread/locking infrastructure is workers. If there are > any synchronization bugs on a platform (or in a specific part of WebKit) > they'll primarily show up as failures in Worker tests. I don't think that's > what is happening here, but it's something to keep in mind. > -atw > > On Mon, Mar 29, 2010 at 6:10 PM, Eric Seidel <[email protected]> wrote: >> >> From my experience watching the bots, I would say the Qt build is >> relatively stable, so I suspect it's just good at reproducing this >> crasher. >> >> The Qt build is nice that it produces stack traces for every crash. >> Sadly their useless until >> https://bugs.webkit.org/show_bug.cgi?id=33654 is fixed. >> >> On Mon, Mar 29, 2010 at 5:47 PM, Drew Wilson <[email protected]> wrote: >> > I'll also note that a disproportionate number of those bugs are >> > happening on >> > the Qt build. This either means that the Qt build is awesome at >> > reproducing >> > this race condition, or that there's some other flakiness on that build >> > that >> > is exposed with workers. >> > -atw >> > >> > On Mon, Mar 29, 2010 at 5:26 PM, Darin Adler <[email protected]> wrote: >> >> >> >> On Mar 29, 2010, at 5:14 PM, Dmitry Titov wrote: >> >> >> >> > JSC workers are terminated by setting a 1-ms timeout. V8 workers >> >> > terminate by throwing exception of a special kind and then checking >> >> > for it >> >> > in C++ code. >> >> >> >> There is precedent in JavaScriptCore for using a special exception to >> >> terminate code. InterruptedExecutionError is used for this purpose. I >> >> could >> >> imagine having something similar for workers. A timeout sounds like a >> >> poor >> >> way to do it. >> >> >> >> -- Darin >> >> >> >> _______________________________________________ >> >> webkit-dev mailing list >> >> [email protected] >> >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > >> > >> > _______________________________________________ >> > webkit-dev mailing list >> > [email protected] >> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > >> > > > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
