Re: Latest buildbot failures (are random?)

[Mark Wielaard <mark@klomp.org>]

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. 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.

The test-suite.log shows:

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?

Cheers,

Mark