Debugging CI test failures
Ben Cooksley
bcooksley at kde.org
Sat Jun 18 10:50:33 BST 2022
On Fri, Jun 17, 2022 at 8:04 AM Thomas Friedrichsmeier <
thomas.friedrichsmeier at kdemail.net> wrote:
> On Thu, 16 Jun 2022 17:31:16 +0200
> Thomas Friedrichsmeier <thomas.friedrichsmeier at kdemail.net> wrote:
>
> > On Thu, 16 Jun 2022 22:26:31 +1200
> > Ben Cooksley <bcooksley at kde.org> wrote:
> >
> > > On Thu, Jun 16, 2022 at 8:08 AM Thomas Friedrichsmeier <
> > > thomas.friedrichsmeier at kdemail.net> wrote:
> > >
> > > > On Wed, 15 Jun 2022 17:51:52 +0200
> > > > Thomas Friedrichsmeier <thomas.friedrichsmeier at kdemail.net> wrote:
> > > > [...]
> > > > > I suppose, I could try seting up some dummy test binaries,
> > > > > linking against the various libraries, hoping to narrow down
> > > > > the problem that way?
> > > >
> > > > Ok, that finally led to something. I have no idea, why this is
> > > > happening, or how to fix it, but I have isolated QWebEngine as the
> > > > troublemaker.
> > > >
> > > > relevant portion of CMakeLists.txt:
> > > >
> > > > add_executable(linktest linktest.cpp)
> > > > target_link_libraries(linktest PRIVATE Qt5::Test
> > > > Qt5::WebEngineWidgets) add_test(NAME rkward-linktest COMMAND
> > > > linktest) ecm_mark_as_test(linktest)
> > > >
> > > > relevant code:
> > > >
> > > >
> https://invent.kde.org/education/rkward/-/blob/work/diagnose_testfailure/rkward/autotests/linktest.cpp
> > > >
> > > > result:
> > > > https://invent.kde.org/education/rkward/-/jobs/359945
> > > >
> > > > (2/2 Test #2: rkward-linktest ..................Exit code
> > > > 0xc0000135)
> > > >
> > > > Note that "new QWebEngineView();" does not even have to be called.
> > > > It's enough that the line of code is present, directly or
> > > > indirectly. In contrast - for instance - creating a
> > > > KTextEditor::Document/View does not cause any trouble.
> > > >
> > >
> > > Interesting. When you build RKward on your local system do you use
> > > the Craft cache or does your system build everything itself?
> > > I wonder if the Craft binaries for WebEngineWidgets are broken - and
> > > MSVC doesn't check down the full chain when it does it's linking.
> >
> > Well, my local craft builds are MinGW-based, and so are using QWebKit,
> > instead. So that does not really compare. No problem, there, however,
> > despite using the cache.
> >
> > I did just check that the latest MSVC build from binary-factory is
> > working. Of course that doesn't contain the test, but rkward itself
> > works fine.
> >
> > I'm currently trying to get my MSVC craft root back to life, but that
> > seems to take another while...
>
> Ok, so no problem (well not _that_ problem, anyway) on craft MSVC 2019
> with Craft cache. That's a Windows 8.1 VM by the way.
>
Strange. Just curious - do we see any additional library dependencies in
WebEngineWidgets that aren't present in the other Qt libraries?
Reason I ask is because the Gitlab CI builds are using Windows Server Core
2022 (LTSC) which is both stripped down compared to a normal Windows
desktop system (Server Core is missing most of the UI stuff), and is based
on the same foundations as Windows 11. The Jenkins based Binary Factory
however uses full traditional Windows 10 Desktop for its builds.
Our Server Core 2022 (LTSC) images do contain .Net 4.8 (including it's SDK)
though which I thought would have given us sufficient coverage but perhaps
there is some part of Windows missing that WebEngine relies on that is
missing here.
>
> Thomas
>
Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20220618/798ed906/attachment.htm>
More information about the kde-devel
mailing list