<div dir="ltr"><div dir="ltr">On Fri, Jun 18, 2021 at 7:33 AM Milian Wolff <<a href="mailto:mail@milianw.de">mail@milianw.de</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Donnerstag, 17. Juni 2021 11:25:15 CEST Ben Cooksley wrote:<br>
> On Thu, Jun 17, 2021 at 8:44 AM Milian Wolff <<a href="mailto:mail@milianw.de" target="_blank">mail@milianw.de</a>> wrote:<br>
> > On Mittwoch, 16. Juni 2021 20:28:25 CEST Ben Cooksley wrote:<br>
> > > Hi all,<br>
> > > <br>
> > > <br>
> > > The following is notice that I intend to withdraw CI services from the<br>
> > > following two KDE projects due to faults in their code or build system<br>
> > > which are having a significant adverse impact on the CI system and<br>
> > > negatively impacting on other projects:<br>
> > > <br>
> > > - KDevelop<br>
> > > - KDE Connect<br>
> > > <br>
> > > This withdrawal will be applied to all platforms.<br>
> > > <br>
> > > In the case of KDevelop, it has a series of unit tests which on FreeBSD<br>
> > > cause gdb to hang and consume an entire CPU core indefinitely. This<br>
> > > slows<br>
> > > down builds for all other projects using that CI server, and also<br>
> > <br>
> > prevents<br>
> > <br>
> > > KWin tests from proceeding - completely blocking it's jobs. This fault<br>
> > > is<br>
> > > in the debuggee_slow family of tests.<br>
> > <br>
> > Hey Ben,<br>
> <br>
> Hi Milian,<br>
> <br>
> > first time I hear of this issue. I simply don't have the capacity to track<br>
> > kdevelop CI mails, so if anything really bad happens, I would really<br>
> > appreciate if anyone who notices that sents a mail to the kdevelop mailing<br>
> > list so we can act on it. I still use kdevelop daily, but don't put any<br>
> > other<br>
> > work in it currently due to lack of time...<br>
> <br>
> The issue in question was noted on #kdevelop (prior to the whole Freenode<br>
> meltdown) on a few occasions.<br>
<br>
Even before that meltdown, I only looked at this when I was directly pinged. <br>
Please prefer to use the mailing lists to get our attention.<br></blockquote><div><br></div><div>Certainly.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> > That said: can we just disable it on the FreeBSD platform, if that's the<br>
> > only<br>
> > one that exhibits this failure? Alternatively I'm obviously fine with<br>
> > skipping<br>
> > that test on that platform, can you give me a link to a failure please so<br>
> > I<br>
> > can see which tests exactly are affected? Then I'll add the QSKIP +<br>
> > platform<br>
> > ifdef checks to skip it on freebsd.<br>
> <br>
> I'm afraid I only have records of the hung test processes (and the gdb<br>
> processes above them using an entire CPU core indefinitely each).<br>
> <br>
> jenkins    60635   0.0  0.0   12120   2256  0  TXs+ 02:44         0:00.00<br>
> /usr/home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5<br>
> FreeBSDQt5.15/build/plugins/debuggercommon/tests/debuggees/debuggee_debugees<br>
> low (debuggee_debugeeslo)<br>
> jenkins    74167   0.0  0.0   12120   2260  1  TXs+ 02:55         0:00.00<br>
> /usr/home/jenkins/workspace/KDevelop/kdevelop/kf5-qt5<br>
> FreeBSDQt5.15/build/plugins/debuggercommon/tests/debuggees/debuggee_debugees<br>
> low (debuggee_debugeeslo)<br>
> <br>
> Hopefully that is enough to identify the tests that are broken?<br>
<br>
I have now added code to skip the tests on FreeBSD wherever debuggeeslow is <br>
used. Unsure which test of the many is actually triggering it, but I have no <br>
time to invest on this either.<br>
<br>
So, is that acceptable for you for now?<br></blockquote><div><br></div><div>That should be perfectly fine - thanks for skipping those tests on FreeBSD.</div><div><br></div><div>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)</div><div><br></div><div>Cheers,</div><div>Ben</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Cheers<br>
<br>
-- <br>
Milian Wolff<br>
<a href="mailto:mail@milianw.de" target="_blank">mail@milianw.de</a><br>
<a href="http://milianw.de" rel="noreferrer" target="_blank">http://milianw.de</a></blockquote></div></div>