Re: Failing tst-initorder2 on glibc master.

[Stefan Liebler <stli at linux dot vnet dot ibm dot com>]

On 06/14/2016 08:50 PM, Carlos O'Donell wrote:
> Stefan,
>
> Do you see any failures on 32-bit s390 with upstream glibc master that
> look like tools issues?
>
> I'm seeing a segfault in elf/tst-initorder2 on RHEL7 with gcc 4.8.5 and
> binutils 2.26.51.20160614 building glibc master (Linux 3.10.0-429.el7.s390x).
>
> (gdb) bt
> #0  __GI__IO_file_doallocate (fp=0x7dff0db8 <_IO_2_1_stdout_>) at filedoalloc.c:101
> #1  0x7def5ac4 in __GI__IO_doallocbuf (fp=fp@entry=0x7dff0db8 <_IO_2_1_stdout_>) at genops.c:398
> #2  0x7def4ef8 in _IO_new_file_overflow (f=0x7dff0db8 <_IO_2_1_stdout_>, ch=-1) at fileops.c:820
> #3  0x7def4166 in _IO_new_file_xsputn (f=0x7dff0db8 <_IO_2_1_stdout_>, data=<optimized out>, n=7) at fileops.c:1331
> #4  0x7deea08c in _IO_puts (str=str@entry=0x7dff75d8 "init: d") at ioputs.c:40
> #5  0x7dff74a2 in init () at tst-initorder2.c:13
> #6  0x555627f0 in call_init (l=<optimized out>, argc=argc@entry=1, argv=argv@entry=0x7ffff0a4, env=env@entry=0x7ffff0ac)
>      at dl-init.c:72
> #7  0x555628e4 in call_init (env=<optimized out>, argv=<optimized out>, argc=<optimized out>, l=<optimized out>)
>      at dl-init.c:119
> #8  _dl_init (main_map=0x55574968, argc=1, argv=0x7ffff0a4, env=0x7ffff0ac) at dl-init.c:120
> #9  0x55555eb8 in _dl_start_user () from /root/build/glibc/elf/ld.so.1
>
> (gdb) si
> 0x7dee7b30	101	  p = malloc (size);
> (gdb)
> 0x7de9afb0 in malloc@plt () from /root/build/glibc/libc.so.6
> (gdb)
> 0x7de9afb4 in malloc@plt () from /root/build/glibc/libc.so.6
> (gdb)
> 0x7bd7c878 in ?? ()
> (gdb)
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x7bd7c878 in ?? ()
>
> The initializer for the test is calling puts which is in turn calling
> malloc via the PLT (quite early on).
>
> $r12 points to libc.so RW data.
> (gdb) i r r12
> r12            0x3ff7dff0000	4395865407488
>
> 7dff0000-7dff2000 rw-p 0016e000 fd:00 36039510                           /root/build/glibc/libc.so
>
> I assume that's the GOT.
>
>     0x7de9afb0 <malloc@plt>:	l	%r1,20(%r12)
>
> (gdb) x/4x $r12 + 20
> 0x7dff0014:	0xfbd7c878	0xd33e6838	0xfbd7d140	0xd33e76a0
>
>     0x7de9afb4 <malloc@plt+4>:	br	%r1
>
> Jumping to 0xfbd7c878 is just garbage.
>
> Unrelocated GOT entry?
>
>     0x7de9afb6 <malloc@plt+6>:	.long	0x00000000
>     0x7de9afba <malloc@plt+10>:	.long	0x00000d10
>     0x7de9afbe <malloc@plt+14>:	l	%r1,14(%r1)
>     0x7de9afc2 <malloc@plt+18>:	j	0x7de9af50
>     0x7de9afc6 <malloc@plt+22>:	.long	0x00000000
>     0x7de9afca <malloc@plt+26>:	.long	0x00000000
>     0x7de9afce <malloc@plt+30>:	.long	0x00185810
>
> 0016f014  0005400b R_390_JMP_SLOT         0007a878   malloc@@GLIBC_2.0 + 0
>
> So the offset looks like it's about right, a page boundary + 0x14 (20).
>
> Does this reproduce for you?

Building and running testsuite with upstream glibc works fine on my 
systems on 32/64bit.
I have build upstream binutils and used them to build glibc.
And now I see segmentation faults in some testcases on 32 and 64bit.
But I haven't looked into them, yet.