From kde-devel Fri Jun 18 19:40:26 2021 From: Ben Cooksley Date: Fri, 18 Jun 2021 19:40:26 +0000 To: kde-devel Subject: Re: Notice of withdrawal of CI services: KDevelop and KDE Connect Message-Id: X-MARC-Message: https://marc.info/?l=kde-devel&m=162404526318374 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--00000000000081181e05c50f7f66" --00000000000081181e05c50f7f66 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 18, 2021 at 7:33 AM Milian Wolff wrote: > On Donnerstag, 17. Juni 2021 11:25:15 CEST Ben Cooksley wrote: > > On Thu, Jun 17, 2021 at 8:44 AM Milian Wolff wrote: > > > On Mittwoch, 16. Juni 2021 20:28:25 CEST Ben Cooksley wrote: > > > > Hi all, > > > > > > > > > > > > The following is notice that I intend to withdraw CI services from > the > > > > following two KDE projects due to faults in their code or build > system > > > > which are having a significant adverse impact on the CI system and > > > > negatively impacting on other projects: > > > > > > > > - KDevelop > > > > - KDE Connect > > > > > > > > This withdrawal will be applied to all platforms. > > > > > > > > In the case of KDevelop, it has a series of unit tests which on > FreeBSD > > > > cause gdb to hang and consume an entire CPU core indefinitely. This > > > > slows > > > > down builds for all other projects using that CI server, and also > > > > > > prevents > > > > > > > KWin tests from proceeding - completely blocking it's jobs. This > fault > > > > is > > > > in the debuggee_slow family of tests. > > > > > > Hey Ben, > > > > Hi Milian, > > > > > first time I hear of this issue. I simply don't have the capacity to > track > > > kdevelop CI mails, so if anything really bad happens, I would really > > > appreciate if anyone who notices that sents a mail to the kdevelop > mailing > > > list so we can act on it. I still use kdevelop daily, but don't put any > > > other > > > work in it currently due to lack of time... > > > > The issue in question was noted on #kdevelop (prior to the whole Freenode > > meltdown) on a few occasions. > > Even before that meltdown, I only looked at this when I was directly > pinged. > Please prefer to use the mailing lists to get our attention. > Certainly. > > > > That said: can we just disable it on the FreeBSD platform, if that's > the > > > only > > > one that exhibits this failure? Alternatively I'm obviously fine with > > > skipping > > > that test on that platform, can you give me a link to a failure please > so > > > I > > > can see which tests exactly are affected? Then I'll add the QSKIP + > > > platform > > > ifdef checks to skip it on freebsd. > > > > I'm afraid I only have records of the hung test processes (and the gdb > > processes above them using an entire CPU core indefinitely each). > > > > jenkins 60635 0.0 0.0 12120 2256 0 TXs+ 02:44 0:00.00 > > /usr/home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5 > > > FreeBSDQt5.15/build/plugins/debuggercommon/tests/debuggees/debuggee_debugees > > low (debuggee_debugeeslo) > > jenkins 74167 0.0 0.0 12120 2260 1 TXs+ 02:55 0:00.00 > > /usr/home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5 > > > FreeBSDQt5.15/build/plugins/debuggercommon/tests/debuggees/debuggee_debugees > > low (debuggee_debugeeslo) > > > > Hopefully that is enough to identify the tests that are broken? > > I have now added code to skip the tests on FreeBSD wherever debuggeeslow > is > used. Unsure which test of the many is actually triggering it, but I have > no > time to invest on this either. > > So, is that acceptable for you for now? > That should be perfectly fine - thanks for skipping those tests on FreeBSD. Please note that it is possible the issue also occurs on Linux however we've no way of knowing if this is the case as the Docker containers are used for one build only and then thrown away (which is also why it isn't an issue there if it is happening, as the process of throwing away the container will kill off any leftover processes) Cheers, Ben > Cheers > > -- > Milian Wolff > mail@milianw.de > http://milianw.de --00000000000081181e05c50f7f66 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jun 18, 2021 at 7:33 AM Milian Wo= lff <mail@milianw.de> wrote:
On Donnerstag, 17. Juni 2021 11:25:15 CEST Ben Cooksley wrote: > On Thu, Jun 17, 2021 at 8:44 AM Milian Wolff <mail@milianw.de> wrote:
> > On Mittwoch, 16. Juni 2021 20:28:25 CEST Ben Cooksley wrote:
> > > Hi all,
> > >
> > >
> > > The following is notice that I intend to withdraw CI service= s from the
> > > following two KDE projects due to faults in their code or bu= ild system
> > > which are having a significant adverse impact on the CI syst= em and
> > > negatively impacting on other projects:
> > >
> > > - KDevelop
> > > - KDE Connect
> > >
> > > This withdrawal will be applied to all platforms.
> > >
> > > In the case of KDevelop, it has a series of unit tests which= on FreeBSD
> > > cause gdb to hang and consume an entire CPU core indefinitel= y. This
> > > slows
> > > down builds for all other projects using that CI server, and= also
> >
> > prevents
> >
> > > KWin tests from proceeding - completely blocking it's jo= bs. This fault
> > > is
> > > in the debuggee_slow family of tests.
> >
> > Hey Ben,
>
> Hi Milian,
>
> > first time I hear of this issue. I simply don't have the capa= city to track
> > kdevelop CI mails, so if anything really bad happens, I would rea= lly
> > appreciate if anyone who notices that sents a mail to the kdevelo= p mailing
> > list so we can act on it. I still use kdevelop daily, but don'= ;t put any
> > other
> > work in it currently due to lack of time...
>
> The issue in question was noted on #kdevelop (prior to the whole Freen= ode
> meltdown) on a few occasions.

Even before that meltdown, I only looked at this when I was directly pinged= .
Please prefer to use the mailing lists to get our attention.

Certainly.
=C2=A0

> > That said: can we just disable it on the FreeBSD platform, if tha= t's the
> > only
> > one that exhibits this failure? Alternatively I'm obviously f= ine with
> > skipping
> > that test on that platform, can you give me a link to a failure p= lease so
> > I
> > can see which tests exactly are affected? Then I'll add the Q= SKIP +
> > platform
> > ifdef checks to skip it on freebsd.
>
> I'm afraid I only have records of the hung test processes (and the= gdb
> processes above them using an entire CPU core indefinitely each).
>
> jenkins=C2=A0 =C2=A0 60635=C2=A0 =C2=A00.0=C2=A0 0.0=C2=A0 =C2=A012120= =C2=A0 =C2=A02256=C2=A0 0=C2=A0 TXs+ 02:44=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A00:00.00
> /usr/home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5
> FreeBSDQt5.15/build/plugins/debuggercommon/tests/debuggees/debuggee_de= bugees
> low (debuggee_debugeeslo)
> jenkins=C2=A0 =C2=A0 74167=C2=A0 =C2=A00.0=C2=A0 0.0=C2=A0 =C2=A012120= =C2=A0 =C2=A02260=C2=A0 1=C2=A0 TXs+ 02:55=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A00:00.00
> /usr/home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5
> FreeBSDQt5.15/build/plugins/debuggercommon/tests/debuggees/debuggee_de= bugees
> low (debuggee_debugeeslo)
>
> Hopefully that is enough to identify the tests that are broken?

I have now added code to skip the tests on FreeBSD wherever debuggeeslow is=
used. Unsure which test of the many is actually triggering it, but I have n= o
time to invest on this either.

So, is that acceptable for you for now?

That should be perfectly fine - thanks for skipping those tests on FreeBSD= .

Please note that it is possible the issue also o= ccurs on Linux however we've no way of knowing if this is the case as t= he Docker containers are used for one build only and then thrown away (whic= h is also why it isn't an issue there if it is happening, as the proces= s of throwing away the container will kill off any leftover processes)

Cheers,
Ben


Cheers

--
Milian Wolff
mail@milianw.de http://m= ilianw.de
--00000000000081181e05c50f7f66--