Status of build bots?

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: Status of build bots?

Florian Weimer-5
* Szabolcs Nagy:

> i do look at the aarch64 and armhf build bots, but i
> was away on holiday for a week.
>
> (aarch64 buildbot is supposed to be green, except for
> occasional FAIL: malloc/tst-malloc-thread-exit, same as
> https://sourceware.org/bugzilla/show_bug.cgi?id=24537
> i might move that test to xtest too. armhf unfortunately
> suffers from an arm64 kernel bug that applies aarch64
> signal stack limits to aarch32 processes, it should be
> fixed in new kernels but i cannot update that machine)
>
> now i see
>
> FAIL: elf/tst-dlopen-aout
> FAIL: elf/tst-dlopen-aout-container
>
> $ elf/ld-linux-aarch64.so.1 --library-path nptl:dlfcn:. elf/tst-dlopen-aout
> error: tst-dlopen-aout.c:48: dlopen succeeded unexpectedly: elf/tst-dlopen-aout
> error: 1 test failures

Does the toolchain default to PIE?  Does the link editor add the
DF_1_PIE flag to the main program?

Thanks,
Florian
Reply | Threaded
Open this post in threaded view
|

Re: Status of build bots?

Szabolcs Nagy-2
On 22/08/2019 12:21, Florian Weimer wrote:

> * Szabolcs Nagy:
>
>> i do look at the aarch64 and armhf build bots, but i
>> was away on holiday for a week.
>>
>> (aarch64 buildbot is supposed to be green, except for
>> occasional FAIL: malloc/tst-malloc-thread-exit, same as
>> https://sourceware.org/bugzilla/show_bug.cgi?id=24537
>> i might move that test to xtest too. armhf unfortunately
>> suffers from an arm64 kernel bug that applies aarch64
>> signal stack limits to aarch32 processes, it should be
>> fixed in new kernels but i cannot update that machine)
>>
>> now i see
>>
>> FAIL: elf/tst-dlopen-aout
>> FAIL: elf/tst-dlopen-aout-container
>>
>> $ elf/ld-linux-aarch64.so.1 --library-path nptl:dlfcn:. elf/tst-dlopen-aout
>> error: tst-dlopen-aout.c:48: dlopen succeeded unexpectedly: elf/tst-dlopen-aout
>> error: 1 test failures
>
> Does the toolchain default to PIE?  Does the link editor add the
> DF_1_PIE flag to the main program?

looks PIE with DF_1_PIE set:

$ readelf -aW elf/tst-dlopen-aout
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           AArch64
  Version:                           0x1
  Entry point address:               0x1834
  Start of program headers:          64 (bytes into file)
  Start of section headers:          90312 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         10
  Size of section headers:           64 (bytes)
  Number of section headers:         38
  Section header string table index: 37

...

Program Headers:
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
  PHDR           0x000040 0x0000000000000040 0x0000000000000040 0x000230 0x000230 R   0x8
  INTERP         0x000270 0x0000000000000270 0x0000000000000270 0x00001b 0x00001b R   0x1
      [Requesting program interpreter: /lib/ld-linux-aarch64.so.1]
  LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x0035d0 0x0035d0 R E 0x10000
  LOAD           0x003b28 0x0000000000013b28 0x0000000000013b28 0x0004e8 0x000518 RW  0x10000
  DYNAMIC        0x003bc0 0x0000000000013bc0 0x0000000000013bc0 0x000220 0x000220 RW  0x8
  NOTE           0x00028c 0x000000000000028c 0x000000000000028c 0x000044 0x000044 R   0x4
  TLS            0x003b28 0x0000000000013b28 0x0000000000013b28 0x000000 0x000004 R   0x4
  GNU_EH_FRAME   0x0030f8 0x00000000000030f8 0x00000000000030f8 0x0000ec 0x0000ec R   0x4
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10
  GNU_RELRO      0x003b28 0x0000000000013b28 0x0000000000013b28 0x0004d8 0x0004d8 R   0x1

...

Dynamic section at offset 0x3bc0 contains 30 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000c (INIT)               0x1480
 0x000000000000000d (FINI)               0x2910
 0x0000000000000019 (INIT_ARRAY)         0x13b28
 0x000000000000001b (INIT_ARRAYSZ)       16 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x13b38
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x0000000000000004 (HASH)               0x2d0
 0x000000006ffffef5 (GNU_HASH)           0x528
 0x0000000000000005 (STRTAB)             0xaa0
 0x0000000000000006 (SYMTAB)             0x548
 0x000000000000000a (STRSZ)              608 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000015 (DEBUG)              0x0
 0x0000000000000003 (PLTGOT)             0x13de0
 0x0000000000000002 (PLTRELSZ)           1104 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x1030
 0x0000000000000007 (RELA)               0xdd8
 0x0000000000000008 (RELASZ)             600 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000000000001e (FLAGS)              BIND_NOW
 0x000000006ffffffb (FLAGS_1)            Flags: NOW PIE
 0x000000006ffffffe (VERNEED)            0xd78
 0x000000006fffffff (VERNEEDNUM)         3
 0x000000006ffffff0 (VERSYM)             0xd00
 0x000000006ffffff9 (RELACOUNT)          13
 0x0000000000000000 (NULL)               0x0

Reply | Threaded
Open this post in threaded view
|

Re: Status of build bots?

Florian Weimer-5
* Szabolcs Nagy:

> On 22/08/2019 12:21, Florian Weimer wrote:
>> * Szabolcs Nagy:
>>
>>> i do look at the aarch64 and armhf build bots, but i
>>> was away on holiday for a week.
>>>
>>> (aarch64 buildbot is supposed to be green, except for
>>> occasional FAIL: malloc/tst-malloc-thread-exit, same as
>>> https://sourceware.org/bugzilla/show_bug.cgi?id=24537
>>> i might move that test to xtest too. armhf unfortunately
>>> suffers from an arm64 kernel bug that applies aarch64
>>> signal stack limits to aarch32 processes, it should be
>>> fixed in new kernels but i cannot update that machine)
>>>
>>> now i see
>>>
>>> FAIL: elf/tst-dlopen-aout
>>> FAIL: elf/tst-dlopen-aout-container
>>>
>>> $ elf/ld-linux-aarch64.so.1 --library-path nptl:dlfcn:. elf/tst-dlopen-aout
>>> error: tst-dlopen-aout.c:48: dlopen succeeded unexpectedly: elf/tst-dlopen-aout
>>> error: 1 test failures
>>
>> Does the toolchain default to PIE?  Does the link editor add the
>> DF_1_PIE flag to the main program?
>
> looks PIE with DF_1_PIE set:

Looks like it.  So the dlopen succeeds because it doesn't load the
object, but somehow recognizes the previously loaded object.

I'll check if I can reproduce this behavior on aarch64.

Thanks,
Florian
Reply | Threaded
Open this post in threaded view
|

Re: Status of build bots?

Szabolcs Nagy-2
In reply to this post by Szabolcs Nagy-2
On 22/08/2019 12:28, Szabolcs Nagy wrote:

> On 22/08/2019 12:21, Florian Weimer wrote:
>> * Szabolcs Nagy:
>>
>>> i do look at the aarch64 and armhf build bots, but i
>>> was away on holiday for a week.
>>>
>>> (aarch64 buildbot is supposed to be green, except for
>>> occasional FAIL: malloc/tst-malloc-thread-exit, same as
>>> https://sourceware.org/bugzilla/show_bug.cgi?id=24537
>>> i might move that test to xtest too. armhf unfortunately
>>> suffers from an arm64 kernel bug that applies aarch64
>>> signal stack limits to aarch32 processes, it should be
>>> fixed in new kernels but i cannot update that machine)
>>>
>>> now i see
>>>
>>> FAIL: elf/tst-dlopen-aout
>>> FAIL: elf/tst-dlopen-aout-container
>>>
>>> $ elf/ld-linux-aarch64.so.1 --library-path nptl:dlfcn:. elf/tst-dlopen-aout
>>> error: tst-dlopen-aout.c:48: dlopen succeeded unexpectedly: elf/tst-dlopen-aout
>>> error: 1 test failures
>>
>> Does the toolchain default to PIE?  Does the link editor add the
>> DF_1_PIE flag to the main program?
>
> looks PIE with DF_1_PIE set:

i use the gcc of ubuntu which has --enable-default-pie,
i wanted to avoid building my own native toolchain.

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/8/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 8.2.0-7ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-8
--program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libquadmath --disable-libquadmath-support --enable-plugin
--enable-default-pie --with-system-zlib --disable-libphobos --enable-multiarch --enable-fix-cortex-a53-843419 --disable-werror
--enable-checking=release --build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Ubuntu 8.2.0-7ubuntu1)


>
> $ readelf -aW elf/tst-dlopen-aout
> ELF Header:
>   Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
>   Class:                             ELF64
>   Data:                              2's complement, little endian
>   Version:                           1 (current)
>   OS/ABI:                            UNIX - System V
>   ABI Version:                       0
>   Type:                              DYN (Shared object file)
>   Machine:                           AArch64
>   Version:                           0x1
>   Entry point address:               0x1834
>   Start of program headers:          64 (bytes into file)
>   Start of section headers:          90312 (bytes into file)
>   Flags:                             0x0
>   Size of this header:               64 (bytes)
>   Size of program headers:           56 (bytes)
>   Number of program headers:         10
>   Size of section headers:           64 (bytes)
>   Number of section headers:         38
>   Section header string table index: 37
>
> ...
>
> Program Headers:
>   Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
>   PHDR           0x000040 0x0000000000000040 0x0000000000000040 0x000230 0x000230 R   0x8
>   INTERP         0x000270 0x0000000000000270 0x0000000000000270 0x00001b 0x00001b R   0x1
>       [Requesting program interpreter: /lib/ld-linux-aarch64.so.1]
>   LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x0035d0 0x0035d0 R E 0x10000
>   LOAD           0x003b28 0x0000000000013b28 0x0000000000013b28 0x0004e8 0x000518 RW  0x10000
>   DYNAMIC        0x003bc0 0x0000000000013bc0 0x0000000000013bc0 0x000220 0x000220 RW  0x8
>   NOTE           0x00028c 0x000000000000028c 0x000000000000028c 0x000044 0x000044 R   0x4
>   TLS            0x003b28 0x0000000000013b28 0x0000000000013b28 0x000000 0x000004 R   0x4
>   GNU_EH_FRAME   0x0030f8 0x00000000000030f8 0x00000000000030f8 0x0000ec 0x0000ec R   0x4
>   GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10
>   GNU_RELRO      0x003b28 0x0000000000013b28 0x0000000000013b28 0x0004d8 0x0004d8 R   0x1
>
> ...
>
> Dynamic section at offset 0x3bc0 contains 30 entries:
>   Tag        Type                         Name/Value
>  0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
>  0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
>  0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
>  0x000000000000000c (INIT)               0x1480
>  0x000000000000000d (FINI)               0x2910
>  0x0000000000000019 (INIT_ARRAY)         0x13b28
>  0x000000000000001b (INIT_ARRAYSZ)       16 (bytes)
>  0x000000000000001a (FINI_ARRAY)         0x13b38
>  0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
>  0x0000000000000004 (HASH)               0x2d0
>  0x000000006ffffef5 (GNU_HASH)           0x528
>  0x0000000000000005 (STRTAB)             0xaa0
>  0x0000000000000006 (SYMTAB)             0x548
>  0x000000000000000a (STRSZ)              608 (bytes)
>  0x000000000000000b (SYMENT)             24 (bytes)
>  0x0000000000000015 (DEBUG)              0x0
>  0x0000000000000003 (PLTGOT)             0x13de0
>  0x0000000000000002 (PLTRELSZ)           1104 (bytes)
>  0x0000000000000014 (PLTREL)             RELA
>  0x0000000000000017 (JMPREL)             0x1030
>  0x0000000000000007 (RELA)               0xdd8
>  0x0000000000000008 (RELASZ)             600 (bytes)
>  0x0000000000000009 (RELAENT)            24 (bytes)
>  0x000000000000001e (FLAGS)              BIND_NOW
>  0x000000006ffffffb (FLAGS_1)            Flags: NOW PIE
>  0x000000006ffffffe (VERNEED)            0xd78
>  0x000000006fffffff (VERNEEDNUM)         3
>  0x000000006ffffff0 (VERSYM)             0xd00
>  0x000000006ffffff9 (RELACOUNT)          13
>  0x0000000000000000 (NULL)               0x0
>

Reply | Threaded
Open this post in threaded view
|

Re: Status of build bots?

Zack Weinberg-2
On Thu, Aug 22, 2019 at 7:34 AM Szabolcs Nagy <[hidden email]> wrote:

> >>> FAIL: elf/tst-dlopen-aout
> >>> FAIL: elf/tst-dlopen-aout-container
> >>>
> >>> $ elf/ld-linux-aarch64.so.1 --library-path nptl:dlfcn:. elf/tst-dlopen-aout
> >>> error: tst-dlopen-aout.c:48: dlopen succeeded unexpectedly: elf/tst-dlopen-aout
> >>> error: 1 test failures
> >>
> >> Does the toolchain default to PIE?  Does the link editor add the
> >> DF_1_PIE flag to the main program?
> >
> > looks PIE with DF_1_PIE set:
>
> i use the gcc of ubuntu which has --enable-default-pie,
> i wanted to avoid building my own native toolchain.

FWIW I am also getting this failure on x86_64 with Debian unstable's
gcc (also configured with --enable-default-pie).

$ elf/ld-linux-x86-64.so.2 --library-path nptl:dlfcn:. elf/tst-dlopen-aout
error: tst-dlopen-aout.c:48: dlopen succeeded unexpectedly: elf/tst-dlopen-aout
error: 1 test failures

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian
9.2.1-2' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++
--prefix=/usr --with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared
--enable-linker-build-id --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --libdir=/usr/lib
--enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror
--with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none,hsa --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-mutex
Thread model: posix
gcc version 9.2.1 20190819 (Debian 9.2.1-2)

 $ readelf -hld elf/tst-dlopen-aout
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              DYN (Shared object file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x2360
  Start of program headers:          64 (bytes into file)
  Start of section headers:          93520 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         12
  Size of section headers:           64 (bytes)
  Number of section headers:         40
  Section header string table index: 39

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  PHDR           0x0000000000000040 0x0000000000000040 0x0000000000000040
                 0x00000000000002a0 0x00000000000002a0  R      0x8
  INTERP         0x00000000000002e0 0x00000000000002e0 0x00000000000002e0
                 0x000000000000001c 0x000000000000001c  R      0x1
      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000001390 0x0000000000001390  R      0x1000
  LOAD           0x0000000000002000 0x0000000000002000 0x0000000000002000
                 0x0000000000001429 0x0000000000001429  R E    0x1000
  LOAD           0x0000000000004000 0x0000000000004000 0x0000000000004000
                 0x0000000000000c88 0x0000000000000c88  R      0x1000
  LOAD           0x0000000000004ce8 0x0000000000005ce8 0x0000000000005ce8
                 0x0000000000000478 0x00000000000004b0  RW     0x1000
  DYNAMIC        0x0000000000004d80 0x0000000000005d80 0x0000000000005d80
                 0x0000000000000210 0x0000000000000210  RW     0x8
  NOTE           0x00000000000002fc 0x00000000000002fc 0x00000000000002fc
                 0x0000000000000044 0x0000000000000044  R      0x4
  TLS            0x0000000000004ce8 0x0000000000005ce8 0x0000000000005ce8
                 0x0000000000000000 0x0000000000000004  R      0x4
  GNU_EH_FRAME   0x0000000000004760 0x0000000000004760 0x0000000000004760
                 0x00000000000000e4 0x00000000000000e4  R      0x4
  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
                 0x0000000000000000 0x0000000000000000  RW     0x10
  GNU_RELRO      0x0000000000004ce8 0x0000000000005ce8 0x0000000000005ce8
                 0x0000000000000318 0x0000000000000318  R      0x1

 Section to Segment mapping:
  Segment Sections...
   00
   01     .interp
   02     .interp .note.gnu.build-id .note.ABI-tag .hash .gnu.hash
.dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt
   03     .init .plt .plt.got .text .fini
   04     .rodata .eh_frame_hdr .eh_frame
   05     .init_array .fini_array .data.rel.ro .dynamic .got .got.plt .data .bss
   06     .dynamic
   07     .note.gnu.build-id .note.ABI-tag
   08     .tbss
   09     .eh_frame_hdr
   10
   11     .init_array .fini_array .data.rel.ro .dynamic .got

Dynamic section at offset 0x4d80 contains 29 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000c (INIT)               0x2000
 0x000000000000000d (FINI)               0x3420
 0x0000000000000019 (INIT_ARRAY)         0x5ce8
 0x000000000000001b (INIT_ARRAYSZ)       16 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x5cf8
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x0000000000000004 (HASH)               0x340
 0x000000006ffffef5 (GNU_HASH)           0x568
 0x0000000000000005 (STRTAB)             0xaa8
 0x0000000000000006 (SYMTAB)             0x598
 0x000000000000000a (STRSZ)              615 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000015 (DEBUG)              0x0
 0x0000000000000003 (PLTGOT)             0x6000
 0x0000000000000002 (PLTRELSZ)           936 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0xfe8
 0x0000000000000007 (RELA)               0xdf0
 0x0000000000000008 (RELASZ)             504 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffb (FLAGS_1)            Flags: PIE
 0x000000006ffffffe (VERNEED)            0xd80
 0x000000006fffffff (VERNEEDNUM)         3
 0x000000006ffffff0 (VERSYM)             0xd10
 0x000000006ffffff9 (RELACOUNT)          8
 0x0000000000000000 (NULL)               0x0

zw
Reply | Threaded
Open this post in threaded view
|

Re: Status of build bots?

Andreas Schwab
In reply to this post by Florian Weimer-5
On Aug 22 2019, Florian Weimer <[hidden email]> wrote:

> * Szabolcs Nagy:
>
>> On 22/08/2019 12:21, Florian Weimer wrote:
>>> * Szabolcs Nagy:
>>>
>>>> i do look at the aarch64 and armhf build bots, but i
>>>> was away on holiday for a week.
>>>>
>>>> (aarch64 buildbot is supposed to be green, except for
>>>> occasional FAIL: malloc/tst-malloc-thread-exit, same as
>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=24537
>>>> i might move that test to xtest too. armhf unfortunately
>>>> suffers from an arm64 kernel bug that applies aarch64
>>>> signal stack limits to aarch32 processes, it should be
>>>> fixed in new kernels but i cannot update that machine)
>>>>
>>>> now i see
>>>>
>>>> FAIL: elf/tst-dlopen-aout
>>>> FAIL: elf/tst-dlopen-aout-container
>>>>
>>>> $ elf/ld-linux-aarch64.so.1 --library-path nptl:dlfcn:. elf/tst-dlopen-aout
>>>> error: tst-dlopen-aout.c:48: dlopen succeeded unexpectedly: elf/tst-dlopen-aout
>>>> error: 1 test failures
>>>
>>> Does the toolchain default to PIE?  Does the link editor add the
>>> DF_1_PIE flag to the main program?
>>
>> looks PIE with DF_1_PIE set:
>
> Looks like it.  So the dlopen succeeds because it doesn't load the
> object, but somehow recognizes the previously loaded object.
>
> I'll check if I can reproduce this behavior on aarch64.

The tests fail everywhere.

Andreas.

--
Andreas Schwab, SUSE Labs, [hidden email]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Reply | Threaded
Open this post in threaded view
|

Re: Status of build bots?

Florian Weimer-5
In reply to this post by Zack Weinberg-2
* Zack Weinberg:

> On Thu, Aug 22, 2019 at 7:34 AM Szabolcs Nagy <[hidden email]> wrote:
>> >>> FAIL: elf/tst-dlopen-aout
>> >>> FAIL: elf/tst-dlopen-aout-container
>> >>>
>> >>> $ elf/ld-linux-aarch64.so.1 --library-path nptl:dlfcn:. elf/tst-dlopen-aout
>> >>> error: tst-dlopen-aout.c:48: dlopen succeeded unexpectedly: elf/tst-dlopen-aout
>> >>> error: 1 test failures
>> >>
>> >> Does the toolchain default to PIE?  Does the link editor add the
>> >> DF_1_PIE flag to the main program?
>> >
>> > looks PIE with DF_1_PIE set:
>>
>> i use the gcc of ubuntu which has --enable-default-pie,
>> i wanted to avoid building my own native toolchain.
>
> FWIW I am also getting this failure on x86_64 with Debian unstable's
> gcc (also configured with --enable-default-pie).
>
> $ elf/ld-linux-x86-64.so.2 --library-path nptl:dlfcn:. elf/tst-dlopen-aout
> error: tst-dlopen-aout.c:48: dlopen succeeded unexpectedly: elf/tst-dlopen-aout
> error: 1 test failures

Thanks, found it.  It's the file identity data in l_file_id for the main
map, yet another difference between kernel loading of the executable and
late loading after an explicit loader invocation.

Unfortunately, after fixing this, the test case fails for PIE
executables with the original assert:

Inconsistency detected by ld.so: ../elf/dl-tls.c: 517: _dl_allocate_tls_init: Assertion `listp != NULL' failed!

Thus the fix for bug 16634 was incorrect. 8-(

This failure reproduces out-of-tree, without an explicit loader
invocation, so it is real.  We just did not have test coverage for this
case before.

On the positive side, all this work on the test wasn't for nothing.  But
it means that I cannot get the test to pass on PIE-by-default toolchains
easily.

Thanks,
Florian
Reply | Threaded
Open this post in threaded view
|

Re: Status of build bots?

Zack Weinberg-2
On 8/22/19 8:43 AM, Florian Weimer wrote:

> Thanks, found it.  It's the file identity data in l_file_id for the main
> map, yet another difference between kernel loading of the executable and
> late loading after an explicit loader invocation.
>
> Unfortunately, after fixing this, the test case fails for PIE
> executables with the original assert:
>
> Inconsistency detected by ld.so: ../elf/dl-tls.c: 517: _dl_allocate_tls_init: Assertion `listp != NULL' failed!
>
> Thus the fix for bug 16634 was incorrect. 8-(
>
> This failure reproduces out-of-tree, without an explicit loader
> invocation, so it is real.  We just did not have test coverage for this
> case before.
>
> On the positive side, all this work on the test wasn't for nothing.  But
> it means that I cannot get the test to pass on PIE-by-default toolchains
> easily.

Suggestion: duplicate this test, compile one copy with explicit -pie and
one with explicit -no-pie, and xfail the -pie version.  That avoids
having testing depend on the configuration of the build toolchain, gets
us back to green buildbots quicker, and we can worry about fixing 16634
properly when someone actually has time to do that.

zw
Reply | Threaded
Open this post in threaded view
|

Re: Status of build bots?

Carlos O'Donell-6
In reply to this post by Joseph Myers
On 8/21/19 12:57 PM, Joseph Myers wrote:

> On Wed, 21 Aug 2019, Florian Weimer wrote:
>
>> * Joseph Myers:
>>
>>> 2019-08-21  Joseph Myers  <[hidden email]>
>>>
>>> * resolv/tst-resolv-ai_idn-latin1.c (do_test): Mark test
>>> unsupported with libidn2 before 2.0.5.
>>> * resolv/tst-resolv-ai_idn.c (do_test): Likewise.
>>
>> This patch looks reasonable to me.  The test still runs on Fedora 30,
>> with libidn 2.2.0.
>
> Carlos, any comments, since you previously said these tests should fail
> with older libidn2?
>

No objection from my side. When I made my previous comments I had not
considered the impact they would have on build bots and CI setups.

We really should be aiming for clean results.

This patch looks good to me.

Reviewed-by: Carlos O'Donell <[hidden email]>

--
Cheers,
Carlos.
Reply | Threaded
Open this post in threaded view
|

Re: Status of build bots?

Florian Weimer-5
In reply to this post by Zack Weinberg-2
* Zack Weinberg:

> On 8/22/19 8:43 AM, Florian Weimer wrote:
>> Thanks, found it.  It's the file identity data in l_file_id for the main
>> map, yet another difference between kernel loading of the executable and
>> late loading after an explicit loader invocation.
>>
>> Unfortunately, after fixing this, the test case fails for PIE
>> executables with the original assert:
>>
>> Inconsistency detected by ld.so: ../elf/dl-tls.c: 517: _dl_allocate_tls_init: Assertion `listp != NULL' failed!
>>
>> Thus the fix for bug 16634 was incorrect. 8-(
>>
>> This failure reproduces out-of-tree, without an explicit loader
>> invocation, so it is real.  We just did not have test coverage for this
>> case before.
>>
>> On the positive side, all this work on the test wasn't for nothing.  But
>> it means that I cannot get the test to pass on PIE-by-default toolchains
>> easily.
>
> Suggestion: duplicate this test, compile one copy with explicit -pie
> and one with explicit -no-pie, and xfail the -pie version.  That
> avoids having testing depend on the configuration of the build
> toolchain, gets us back to green buildbots quicker, and we can worry
> about fixing 16634 properly when someone actually has time to do that.

We have a partner bug report about this, so it's likely I have to fix
this properly anyway.

My hunch is that the assert can also happen if dlopen fails much, much
later, in relocation processing, and that could be the actually relevant
case (I don't know that yet, I need to write a different glibc test for
that).

Thanks,
Florian
Reply | Threaded
Open this post in threaded view
|

Re: Status of build bots?

Zack Weinberg-2
On 8/22/19 8:55 AM, Florian Weimer wrote:

> * Zack Weinberg:
>
>> On 8/22/19 8:43 AM, Florian Weimer wrote:
>>> Thanks, found it.  It's the file identity data in l_file_id for the main
>>> map, yet another difference between kernel loading of the executable and
>>> late loading after an explicit loader invocation.
>>>
>>> Unfortunately, after fixing this, the test case fails for PIE
>>> executables with the original assert:
>>>
>>> Inconsistency detected by ld.so: ../elf/dl-tls.c: 517: _dl_allocate_tls_init: Assertion `listp != NULL' failed!
>>>
>>> Thus the fix for bug 16634 was incorrect. 8-(
>>>
>>> This failure reproduces out-of-tree, without an explicit loader
>>> invocation, so it is real.  We just did not have test coverage for this
>>> case before.
>>>
>>> On the positive side, all this work on the test wasn't for nothing.  But
>>> it means that I cannot get the test to pass on PIE-by-default toolchains
>>> easily.
>>
>> Suggestion: duplicate this test, compile one copy with explicit -pie
>> and one with explicit -no-pie, and xfail the -pie version.  That
>> avoids having testing depend on the configuration of the build
>> toolchain, gets us back to green buildbots quicker, and we can worry
>> about fixing 16634 properly when someone actually has time to do that.
>
> We have a partner bug report about this, so it's likely I have to fix
> this properly anyway.

Oh, OK.  I _was_ trying to get you off the hook here since you seem like
you might be overcommitted, but a proper fix would of course be better.

I still think it would be a good idea to duplicate the test, compile one
copy with explicit -pie, and one copy with explicit -no-pie, to remove
the dependency on build toolchain configuration.

zw
Reply | Threaded
Open this post in threaded view
|

Re: Status of build bots?

Tulio Magno Quites Machado Filho-2
In reply to this post by Carlos O'Donell-6
Carlos O'Donell <[hidden email]> writes:

> The buildbots look red across the board.
>
> Do we know what's up with them?

I lost access to ppc* at the beginning of the year and I still need to
recreate them.

> Do we have an "ownership" page on the wiki so I can
> reach out and offer support in some way to the owners
> of that hardware?

The best we have right now is:
https://sourceware.org/glibc/wiki/MAINTAINERS#Maintainers_for_BuildBot

But it doesn't list the owners of BuildBot workers yet.

--
Tulio Magno
Reply | Threaded
Open this post in threaded view
|

Re: Status of build bots?

Tulio Magno Quites Machado Filho-2
In reply to this post by Stefan Liebler-2
Stefan Liebler <[hidden email]> writes:

> On 8/20/19 11:08 PM, Carlos O'Donell wrote:
>> Just look at Sergio's gdb buildbot and how nice it is to see logs snippets etc.
>> https://gdb-buildbot.osci.io/#/
>>
> I've just had a look to the gdb buildbot.
> You can see that the builds were green (all fine) or red (fails).
> But compared to glibc buildbot, it's much easier and faster to see which
> tests have failed (see regressions in the build summary).
>
> We could also distinguish somehow between red (fails) and red* (fails,
> but further fails appeared or are now passing compared to last build)

Notice the GDB buildbot has a mechanism to distinguish between new failures
(regressions) and existent failures, e.g.
https://gdb-buildbot.osci.io/#/builders/7/builds/542

This is important because it avoids hiding a second regression while we're
fixing the first one.

> Perhaps we could also dump the out files of all failing tests.
> At least sometimes this would help.

I think the following steps would be helpful:

    # Send a script to capture the output of testcases from the
    # master to the slave.
    self.factory.addStep(
    FileDownload(
    mastersrc='glibc-report.sh',
    workerdest='glibc-report.sh'
    )
    )
    #
    # Collect the output from the tests that failed.
    self.factory.addStep(
    ShellCommand(
    name="report",
    command=[
    "bash",
    "./glibc-report.sh"
    ],
    workdir="vpath",
    warnOnFailure=True,
    )
    )

Where glibc-report.sh is:

    #/bin/bash
   
    files=$(find . -name '*.test-result');
    for f in ${files}; do
    if ! grep -qE "PASS|XFAIL|UNSUPPORTED" "${f}"; then
    out=$(echo ${f} | sed -e 's/\.test-result/.out/');
    echo "---=== ${out} ===---";
    cat "${out}"
    echo
    cat "${f}"
    echo
    fi;
    done

--
Tulio Magno
Reply | Threaded
Open this post in threaded view
|

Re: Status of build bots?

Stefan Liebler-2
In reply to this post by Mark Wielaard
On 8/22/19 11:47 AM, Mark Wielaard wrote:

> On Thu, Aug 22, 2019 at 09:35:36AM +0200, Stefan Liebler wrote:
>> I've just had a look into the logs of some of the last builds of s390x
>> buildbot (before it was down). There I could always see: "No space left on
>> device".
>
> It was actually a file sytem corruption, that showed up as "no space
> left".  The problem is that for other projects using this machine for
> their buildbot it was quickly noticed and reported, but for glibc
> nobody seemed to be monitoring the results.
>
> Also before that file system issue the build also didn't work.  And
> all other buildbot workers also look red (for months).  The problem is
> that there is no known "good set" of test results and since there are
> always build steps or tests failing you cannot determine if something
> is a bad regression or "just" a (known?) failing testcase.
>
> I think before we resurrect the buildbot workers (for whichever
> architecture), we should see if we can define a minumum build and test
> setup that should always PASS and make the buildbot sent warnings if
> that changes. And make sure that someone monitors the results. And/Or
> that making a buildbot worker turn red is a reason for reverting a
> commit.
>
> Cheers,
>
> Mark
>
I've had a look at some older builds:

Can anybody help to find out what was going wrong here:
http://glibc-buildbot.reserved-bit.com/builders/glibc-s390x-linux/builds/2640/steps/check%20%28clobber%29/logs/stdio
I've only see:
make[1]: *** [Makefile:412: tests] Error 1
make[1]: Target 'check' not remade because of errors.
make[1]: Leaving directory
'/home/mjw/glibc/build/glibc-s390x-linux/build/glibc'
make: *** [Makefile:9: check] Error 2



Some other builds show those FAILs:

In your previous post, you've said "The s390x worker is somewhat
overloaded". Sometimes, I also see fails on machines where either the
current system itself or other lpars/zVM-guests are "overloaded".
FAIL: nptl/tst-create-detached
FAIL: nptl/tst-mutex10
=> then, you'll see timeouts
FAIL: rt/tst-cpuclock1
=> then, you'll see something like that "before - after 0.690189364
outside reasonable range"


FAIL: nss/tst-nss-files-hosts-getent
FAIL: nss/tst-nss-files-hosts-long
=> I've only saw this due to bug fixed with "test-container: Install
with $(sorted-subdirs) [BZ #24794]"
(https://sourceware.org/git/?p=glibc.git;a=commit;h=354e4c1adddb1da19c1043e3e5db61ee2148d912)
But I don't know if this was the case in the buildbot-build.

I've never seen these fails before. Does those also time out?
FAIL: nptl/tst-mutexpi7a
FAIL: nptl/tst-thread-affinity-pthread2

Reply | Threaded
Open this post in threaded view
|

Re: Status of build bots?

Joseph Myers
In reply to this post by Tulio Magno Quites Machado Filho-2
On Thu, 22 Aug 2019, Tulio Magno Quites Machado Filho wrote:

> Notice the GDB buildbot has a mechanism to distinguish between new failures
> (regressions) and existent failures, e.g.
> https://gdb-buildbot.osci.io/#/builders/7/builds/542
>
> This is important because it avoids hiding a second regression while we're
> fixing the first one.

That's useful while we don't have a fully clean baseline - but fully
clean baselines are still valuable (so new contributors don't need to
discover for themselves which FAILs are expected, so distributors don't
all need to replicate their own lists of expected FAILs, etc.).

>     files=$(find . -name '*.test-result');

List should be sorted to avoid being in a random order.

>     for f in ${files}; do
>     if ! grep -qE "PASS|XFAIL|UNSUPPORTED" "${f}"; then
>     out=$(echo ${f} | sed -e 's/\.test-result/.out/');

out=${f%.test-result}.out

>     echo "---=== ${out} ===---";
>     cat "${out}"

Note that ${out} might not exist in some cases.

--
Joseph S. Myers
[hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Status of build bots?

Florian Weimer-5
In reply to this post by Zack Weinberg-2
* Zack Weinberg:

> On 8/22/19 8:55 AM, Florian Weimer wrote:
>> * Zack Weinberg:
>>
>>> On 8/22/19 8:43 AM, Florian Weimer wrote:
>>>> Thanks, found it.  It's the file identity data in l_file_id for the main
>>>> map, yet another difference between kernel loading of the executable and
>>>> late loading after an explicit loader invocation.
>>>>
>>>> Unfortunately, after fixing this, the test case fails for PIE
>>>> executables with the original assert:
>>>>
>>>> Inconsistency detected by ld.so: ../elf/dl-tls.c: 517: _dl_allocate_tls_init: Assertion `listp != NULL' failed!
>>>>
>>>> Thus the fix for bug 16634 was incorrect. 8-(
>>>>
>>>> This failure reproduces out-of-tree, without an explicit loader
>>>> invocation, so it is real.  We just did not have test coverage for this
>>>> case before.
>>>>
>>>> On the positive side, all this work on the test wasn't for nothing.  But
>>>> it means that I cannot get the test to pass on PIE-by-default toolchains
>>>> easily.
>>>
>>> Suggestion: duplicate this test, compile one copy with explicit -pie
>>> and one with explicit -no-pie, and xfail the -pie version.  That
>>> avoids having testing depend on the configuration of the build
>>> toolchain, gets us back to green buildbots quicker, and we can worry
>>> about fixing 16634 properly when someone actually has time to do that.
>>
>> We have a partner bug report about this, so it's likely I have to fix
>> this properly anyway.
>
> Oh, OK.  I _was_ trying to get you off the hook here since you seem like
> you might be overcommitted, but a proper fix would of course be better.
>
> I still think it would be a good idea to duplicate the test, compile one
> copy with explicit -pie, and one copy with explicit -no-pie, to remove
> the dependency on build toolchain configuration.

It's still a good suggestion.  I've posted both fixes now, and the fix
for bug 24930 is very difficult to review, so maybe we'll have to use
the stopgap measure.

Thanks,
Florian
Reply | Threaded
Open this post in threaded view
|

Re: Status of build bots?

DJ Delorie-2
In reply to this post by Szabolcs Nagy-2

Szabolcs Nagy <[hidden email]> writes:
> This results in an unnecessary difference between glibc testing
> (without --enable-hardcoded-path-in-tests) and production usage.

This sounds like the kind of test that should be done in a
test-container.
Reply | Threaded
Open this post in threaded view
|

Re: Status of build bots?

Mark Wielaard
In reply to this post by Tulio Magno Quites Machado Filho-2
On Thu, 2019-08-22 at 10:51 -0300, Tulio Magno Quites Machado Filho wrote:
> Carlos O'Donell <[hidden email]> writes:
> > Do we have an "ownership" page on the wiki so I can
> > reach out and offer support in some way to the owners
> > of that hardware?
>
> The best we have right now is:
> https://sourceware.org/glibc/wiki/MAINTAINERS#Maintainers_for_BuildBot
>

I see I am on that list. But if I have access to the buildbot master,
then I forgot, sorry. I believe I only have access to one buildbot
worker instance for a Fedora s390x setup (which is currently
disconnected).

> But it doesn't list the owners of BuildBot workers yet.

The buildbot worker admins are listed here:

http://glibc-buildbot.reserved-bit.com/buildslaves

Cheers,

Mark
12