This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Failing tst-initorder2 on glibc master.

On 06/14/2016 08:50 PM, Carlos O'Donell wrote:

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

(gdb) si
0x7dee7b30	101	  p = malloc (size);
0x7de9afb0 in malloc@plt () from /root/build/glibc/
0x7de9afb4 in malloc@plt () from /root/build/glibc/
0x7bd7c878 in ?? ()

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 RW data.
(gdb) i r r12
r12            0x3ff7dff0000	4395865407488

7dff0000-7dff2000 rw-p 0016e000 fd:00 36039510                           /root/build/glibc/

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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]