Re: Jenkins-kde-ci: kdbusaddons master kf5-qt5 » Linux, gcc - Build # 11 - Still Unstable!

Mon Apr 25 07:42:22 UTC 2016

On Mon, Apr 25, 2016 at 7:29 PM, Albert Astals Cid <aacid at kde.org> wrote:
> I object.
>
> a) I already told you, don't use something nobody else uses, use the
> separate repos

Umm, since when? To my knowledge kdesrc-build uses qt5.git.
The Qt developers might not, but I don't care one bit what they do,
it's what we do that matters.

In any event, this would make updating Qt a complete and utter
nightmare, especially if inter-module building breaks at some point
(i've been told this is why qt5.git sometimes get stuck for
weeks/months without updates - so it definitely happens more often
than not).

I'd rather not be exposed to Qt politics between modules, because
they've broken their internal BC (and they'll break it, that much i'm
sure - they broke BC in the move from Qt 5.5 to 5.6 requiring a
rebuild of kdelibs4support so don't say the Qt developers know about
BC, because they don't. If they can't manage it for external
interfaces, they definitely won't be able to for "internal" ones)

Not to mention we have to get our build order right if things depend
on more than just qtcore (which i'm almost certain will be the case)

> b) Not going to happen, but why would it matter at all?
>
> More reasons for it:
>  c) ASAN does not check for things in the library being broken or not since
> it only works on code compiled with ASAN, so the crashes are not in the
> library, they are in your code (if they are because of the library being
> broken or not that's not important, *your* code is the one that is going to
> crash)

To my knowledge we don't compile Qt with ASAN support (considering one
has to tell the build system / compiler / linker to bring it in, and
we definitely don't do anything special here).
The backtraces quite clearly show that the code in question going bang
is deep inside Qt, and David confirmed that it's 100% a Qt bug and
nothing we can workaround.

>  d) Hiding your head in the sand and saying "this is not my fault it's Qt's
> fault" is not going to fix the fact that your code is crashing
>  e) We've uncovered bugs that otherwise would have bitten us and nobody
> would have bothered fixing because they would be hardly reproducible, both
> in our code and in Qt's code, that is a *good* thing, not a bad thing.

I'll agree that it's a good thing.
What's bad is that we have to deal with Qt, who as far as i'm
concerned at least are not responsive enough to our complaints, and
are far too slow.

>
>
> Let's not move backwards.
>
> Cheers,
>   Albert

Regards,
Ben

>
> ________________________________
> De: Ben Cooksley <bcooksley at kde.org>
> Para: Martin Graesslin <mgraesslin at kde.org>
> CC: Scarlett Clark <sgclark at kde.org>; "kde-frameworks-devel at kde.org"
> <kde-frameworks-devel at kde.org>
> Enviado: Lunes 25 de abril de 2016 9:14
> Asunto: Re: Jenkins-kde-ci: kdbusaddons master kf5-qt5 » Linux, gcc - Build
> # 11 - Still Unstable!
>
> On Mon, Apr 25, 2016 at 5:59 PM, Martin Graesslin <mgraesslin at kde.org>
> wrote:
>> On Saturday, April 23, 2016 8:48:17 PM CEST Ben Cooksley wrote:
>>> On Sat, Apr 23, 2016 at 8:35 PM, Martin Graesslin <mgraesslin at kde.org>
>> wrote:
>>> > On Saturday, April 23, 2016 1:09:00 PM CEST Ben Cooksley wrote:
>>> >> On Sat, Apr 23, 2016 at 1:04 PM, Daniel Vrátil <dvratil at kde.org>
>>> >> wrote:
>>> >> > On Saturday, April 23, 2016 1:44:16 AM CEST Ben Cooksley wrote:
>>> >> >> On Fri, Apr 22, 2016 at 11:11 PM, David Faure <faure at kde.org>
>>> >> >> wrote:
>>> >> >> > On Thursday 21 April 2016 14:57:52 no-reply at kde.org wrote:
>>> >> >> >> GENERAL INFO
>>> >> >> >>
>>> >> >> >> BUILD UNSTABLE
>>> >> >> >> Build URL:
>>> >> >> >>
>>> >> >> >> https://build.kde.org/job/kdbusaddons%20master%20kf5-qt5/PLATFORM=L
>>> >> >> >> inu
>>> >> >> >> x,
>>> >> >> >> compiler=gcc/11/>
>>> >> >> >
>>> >> >> > Wow, ASAN detected a real bug in Qt here.
>>> >> >> >
>>> >> >> > Fixed in https://codereview.qt-project.org/156728
>>> >> >>
>>> >> >> As this issue essentially breaks any test on the CI system that
>>> >> >> depends on Qt I suggest all developers affected by this indicate
>>> >> >> this
>>> >> >> on the relevant reviews.
>>> >> >
>>> >> > Hey guys,
>>> >>
>>> >> Hi David,
>>> >>
>>> >> > any chance to get this patch into our Qt build on the CI since it
>>> >> > has
>>> >> > been
>>> >> > integrated upstream now? As it affects all tests that interact with
>>> >> > DBus
>>> >> > it
>>> >> > would be nice to resolve this on the CI.
>>> >>
>>> >> We'll need upstream to update qt5.git (I think that's still required
>>> >> for changes to fully flow through) I think.
>>> >> We could try to hack the patch in, but then we'll end up having to
>>> >> undo that in a few weeks time.
>>> >
>>> > Could we disable that ASAN check please[1]? I have two of my projects
>>> > failing due to the DBus problem and one further failing due to a
>>> > similar
>>> > problem in QQuickStyleItem [2]. It's nice that we find errors, but I
>>> > rather not have my tests fail due to errors in Qt.
>>>
>>> That would just cover up the issue.
>>
>> Yes it would and that's exactly what I want.
>>
>> To me the CI is currently producing false positives. It started to break
>> from
>> one moment to the other. It costs time to look into why it started to
>> fail. It
>> means that till that problem is fixed in Qt I cannot trust the CI system.
>> It
>> results in nobody noticing real breakage, because the build is broken
>> anyway.
>>
>> Then there is the problem of responsibility: I look at the output, I have
>> no
>> idea why that thing is broken, I have no idea how to build a minimal
>> example
>> which would reproduce it, even less on how to fix it. That's just a really
>> bad
>> situation to have a CI which can be trusted.
>>
>> In summary: I don't want spend time to investigate false positives. If an
>> option results in false positives, I think that we should disable it.
>
> Understandable.
>
>>
>> Of course Qt should get those bugs fixed, but for that Qt should enable
>> ASAN on
>> their CI system. If we get libraries which are free of ASAN problems, then
>> we
>> can enable it on our side. But false positives are just bad.
>
> Based on this i'm going to assume Qt is not ASAN compliant, and will
> therefore be disabling ASAN for all KDE projects across the entire KDE
> CI system in 24 hours unless nobody objects.
>
> Objectors can be expected to place pressure on the appropriate
> processes within the Qt Project to:
> a) Get the necessary changes flowed through into qt5.git so we can
> pick them up (the existing process is painfully slow)
> b) Get their CI system to check for ASAN issues.
>
>>
>> Cheers
>> Martin
>
> Regards,
>
> Ben
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>
>
>
> _______________________________________________
> Kde-frameworks-devel mailing list
> Kde-frameworks-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
>