Re: Latest buildbot failures (are random?)

[Dodji Seketeli <dodji@seketeli.org>]

Mark Wielaard <mark@klomp.org> a écrit:

> On Tue, 2019-04-16 at 22:58 +0200, Mark Wielaard wrote:
>> Hi,
>> 
>> So the latest patches all seemed to cause some builder to fail some
>> testcase. But not always on the same architecture and not always the
>> same testcase. For the last 12 commits only centos-aarch64 was
>> completely green.
>> 
>> https://builder.wildebeest.org/buildbot/#/builders?tags=libabigail
>> https://builder.wildebeest.org/buildbot/#/console
>> 
>> I suspect the "Fold away const for array types" patch. All failures
>> look like somehow a const <type> is moved around, messing up the
>> type-
>> ids numbering. Might the re_canonicalization somehow introduce non-
>> deterministic ordering of the types?
>
> Maybe that is wrong. 

Yeah, maybe.  But the logic of editing canonicalized types was not good
in any case, IMHO.  So I stopped doing that.  We'll see how it goes.

> If you look at the last failure:
> https://builder.wildebeest.org/buildbot/#/builders/7/builds/246
> There doesn't seem to be a const array type involved.

Indeed.

[...]

> FAIL: runtestreaddwarf
> ======================
>
> --- /srv/buildbot/worker/libabigail-fedora-x86_64/build/tests/data/test-read-dwarf/test9-pr18818-clang.so.abi	2019-04-16 17:46:57.279685814 +0200
> +++ /srv/buildbot/worker/libabigail-fedora-x86_64/build/tests/output/test-read-dwarf/test9-pr18818-clang.so.abi	2019-04-17 08:04:25.541144939 +0200
> @@ -1611,7 +1611,7 @@
>        <return type-id='type-id-5'/>
>      </function-decl>
>      <qualified-type-def type-id='type-id-114' restrict='yes' id='type-id-115'/>
> -    <typedef-decl name='_G_fpos_t' type-id='type-id-62' filepath='/usr/include/_G_config.h' line='25' column='1' id='type-id-116'/>
> +    <typedef-decl name='_G_fpos_t' type-id='type-id-88' filepath='/usr/include/_G_config.h' line='25' column='1' id='type-id-116'/>
>      <typedef-decl name='fpos_t' type-id='type-id-116' filepath='/usr/include/stdio.h' line='110' column='1' id='type-id-117'/>
>      <pointer-type-def type-id='type-id-117' size-in-bits='64' id='type-id-118'/>
>      <qualified-type-def type-id='type-id-118' restrict='yes' id='type-id-119'/>
> FAIL runtestreaddwarf (exit status: 1)
>
> So the difference is the type-id for _G_fpos_t. 62 vs 88.
> Where 62 is:
>
>     <class-decl name='__anonymous_struct__' size-in-bits='64' is-struct='yes' is-anonymous='yes' naming-typedef-id='type-id-61' visibility='default' is-declaration-only='yes' id='type-id-62'/>
>     <typedef-decl name='div_t' type-id='type-id-62' filepath='/usr/include/stdlib.h' line='101' column='1' id='type-id-61'/>
>
> And 88 is"
>
>     <class-decl name='__anonymous_struct__' size-in-bits='64' is-struct='yes' is-anonymous='yes' naming-typedef-id='type-id-87' visibility='default' filepath='/usr/include/wchar.h' line='82' column='1' id='type-id-88'>
> [...]
>     <typedef-decl name='__mbstate_t' type-id='type-id-88' filepath='/usr/include/wchar.h' line='94' column='1' id='type-id-87'/>
>
> Where we seem to describe the following:
>
> typedef struct
> {
>   __off_t __pos;
>   __mbstate_t __state;
> } _G_fpos_t;
>
> I don't think I understand what is going on, or how anonymous structs are represented. But it doesn't seem to have anything to do with const arrays?

Right.  There was a recent commit that had to do with the de-duplication
of anonymous structs DIEs.  I'll think about the possible effects of
that one.  Of course, I am not seeing this error locally here :(

Thanks for spotting these issues.  It's really appreciated.

Cheers,

-- 
		Dodji