[PATCH] Implement timestamp'ed output on "make check"

Sergio Durigan Junior sergiodj@redhat.com
Wed Dec 5 19:48:00 GMT 2018


On Wednesday, December 05 2018, Pedro Franco de Carvalho wrote:

> Sergio Durigan Junior <sergiodj@redhat.com> writes:
>
>> It is unfortunately not uncommon to have tests hanging on some of the
>> BuildBot workers.  For example, the ppc64be/ppc64le+gdbserver builders
>> are especially in a bad state when it comes to testing GDB/gdbserver,
>> and we can have builds that take an absurd amount of time to
>> finish (almost 1 week for one single build, for example).
>>
>> It may be hard to diagnose these failures, because sometimes we don't
>> have access to the faulty systems, and other times we're just too busy
>> to wait and check which test is actually hanging.  During one of our
>> conversations about the topic, someone proposed that it would be a
>> good idea to have a timestamp put together with stdout output, so that
>> we can come back later and examine which tests are taking too long to
>> complete.
>
> Hello Sergio,

Hey Pedro,

> I've looked into the ppc64le native-gdbserver/native-extended-gdbserver
> buildbot workers, it seems that they started getting slower with this
> patch:
>
> f19c7ff839d7a32ebb48482ae7d318fb46ca823d
> GDBSERVER: Listen on a unix domain (instead of TCP) socket if requested.

>From my recollection, ISTR that the gdbserver builders were *very* slow
even before this commit.  I was even talking to Edjunior about disabling
the gdbserver builders, because they were just contributing to making
the queue larger for the native builder.

> I believe this patch has been reverted, but the builders haven't reached
> the reverted point yet.  Would it make sense to make the workers resume
> after the reverted patch?  This would be at commit
> 80e24d09860dbeba7d435b4a4f0990f85dbc084e.
>
> They did also get even slower after this patch:
>
> fe1a5cad302b5535030cdf62895e79512713d738
> [gdb/testsuite] Log wait status on process no longer exists error
>
> But I think it only happens in combination with the patch above (see
> https://sourceware.org/ml/gdb-patches/2018-12/msg00060.html for a more
> detailed explanation).

Alright.  I'll try to cancel the builds up until
80e24d09860dbeba7d435b4a4f0990f85dbc084e and see how things go.

Thanks for taking the time to investigate this!

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/



More information about the Gdb-patches mailing list