Bug 77653 – [Qt] Fix new Qt5 bugs

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Csaba Osztrogonác]

Today I tried the latest Qt5 hash for the weekly update, but unfortunately 
there is a serious assertion should be fixed before updating. (WK1 and WK2 too)
Zillion tests crash, but the crash log is same for all crash.

crash log on WK2: ( Unfortunately it is empty on WK1 :-/ )
ASSERTION FAILED: m_transparencyCount > 0
/home/oszi/WebKit/Source/WebCore/platform/graphics/GraphicsContext.cpp(346) : void WebCore::GraphicsContext::endTransparencyLayer()

Unfortunately the bug isn't reproducible easily, becuase crashing tests pass with --run-singly
But you can reproduce them easily and deterministically with:
$ Tools/Scripts/run-webkit-tests --debug svg/clip-path

Should we postpone the update, or should we find a previous, but working Qt5 hash of this week?

[Csaba Osztrogonác]

I forgot to mention the Qt5 hash: 48a84504374730c6eb14c265f2fe96a4cfe02294

[Csaba Osztrogonác]

(In reply to comment #1)
> I forgot to mention the Qt5 hash: 48a84504374730c6eb14c265f2fe96a4cfe02294

I made a manual bisecting, 48a84504374730c6eb14c265f2fe96a4cfe02294 is the culprit, the hash before it works fine. (ebf10988f49c31f3bcf595a1e043cdac47c3e138)

Should we update to the latest working hash?

[Simon Hausmann]

(In reply to comment #2)
> (In reply to comment #1)
> > I forgot to mention the Qt5 hash: 48a84504374730c6eb14c265f2fe96a4cfe02294
> 
> I made a manual bisecting, 48a84504374730c6eb14c265f2fe96a4cfe02294 is the culprit, the hash before it works fine. (ebf10988f49c31f3bcf595a1e043cdac47c3e138)
> 
> Should we update to the latest working hash?

Yeah, it's better than nothing. It includes a fix in QImage that we need and it includes some fixes for Harmattan. Unfortunately it's also missing a fix in qtdeclarative for touch events, so without that fix the touch screen is unusable. But that one fix can be cherry-picked by those who need it.

I'd say go for the working hash and let's keep this bug open until we tracked down what causes the crashes.

[Csaba Osztrogonác]

I updated the bots to 48a84504374730c6eb14c265f2fe96a4cfe02294, but unfortunately we got strange crashes on Qt-WK1:
http://build.webkit.sed.hu/results/x86-32%20Linux%20Qt%20Release%20-%20Qt5-WebKit1/r106660%20%283116%29/results.html

and strange timeouts on WK2: (timeout/pass flakiness)
http://build.webkit.sed.hu/results/x86-32%20Linux%20Qt%20Release%20WebKit2/r106663%20%2819652%29/results.html

I checked wk1 tests, a065c70489e96aa254089a666c0a6fcc89c50825 was the latest working hash, the next cab9e353192b34a411122e718c8810e7cc342d29 hash has this bug.

[Simon Hausmann]

(In reply to comment #4)
> I updated the bots to 48a84504374730c6eb14c265f2fe96a4cfe02294, but unfortunately we got strange crashes on Qt-WK1:
> http://build.webkit.sed.hu/results/x86-32%20Linux%20Qt%20Release%20-%20Qt5-WebKit1/r106660%20%283116%29/results.html
> 
> and strange timeouts on WK2: (timeout/pass flakiness)
> http://build.webkit.sed.hu/results/x86-32%20Linux%20Qt%20Release%20WebKit2/r106663%20%2819652%29/results.html
> 
> I checked wk1 tests, a065c70489e96aa254089a666c0a6fcc89c50825 was the latest working hash, the next cab9e353192b34a411122e718c8810e7cc342d29 hash has this bug.

I'm investigating, and what seems like a crash appears to be DRT _exiting_ after completing the test. That would also explain the lack of backtraces. I suspect the event loop changes in qtbase.

[Simon Hausmann]

I've filed https://bugreports.qt-project.org/browse/QTBUG-24120 with a test-case. We can work around the issue for now. I'll submit a patch that is safe to do in any case.

[Csaba Osztrogonác]

And have you got any idea for strange WK2 flakiness? (TIMEOUT and then PASS on the second run)

[Csaba Osztrogonác]

Created attachment 126105 [details]
WIP buildfix patch

I tried the latest Qt5 c4ebe393de42d16314b27ae024087fa942436474
with this patch: http://codereview.qt-project.org/#change,15625
After it will be landed in Qt5 trunk and after minor WebKit 
buildfixes we can do the update.

WK1 and WK2 layouttests works fine locally, but we still have
some problems with API tests. I had to disable qdeclarativewebview
API tests, because it has build problems (missing symbols.)

I'll continue the digging tomorrow.

[Simon Hausmann]

Comment on attachment 126105 [details]
WIP buildfix patch

Patch LGTM, but yeah, it'd be good to know what caused the test problems.

[Simon Hausmann]

Created attachment 126266 [details]
Patch

[Csaba Osztrogonác]

Comment on attachment 126266 [details]
Patch

Clearing flags on attachment: 126266

Committed r107221: <http://trac.webkit.org/changeset/107221>

[Csaba Osztrogonác]

All reviewed patches have been landed.  Closing bug.