diff mbox

glibc 2.22 -- Final testing for 32-bit x86 failing?

Message ID CALoOobPwKv003N5BMcPQ+QThRkfpk9s5Ev86srZa+JuCSvf6DA@mail.gmail.com
State Committed
Headers

Commit Message

Paul Pluzhnikov Aug. 1, 2015, 10:27 p.m. UTC 
  On Sat, Aug 1, 2015 at 1:03 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Sat, Aug 1, 2015 at 12:27 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>> Community,
>>
>> Has anyone else done 32-bit x86 testing and had it work? Top of master
>> is showing some kind of problem with memory corruption.
>>
>> memory clobbered past end of allocated block
>>
>> Program received signal SIGABRT, Aborted.
>> 0xf7ffdc10 in __kernel_vsyscall ()
>> (gdb) bt
>> #0  0xf7ffdc10 in __kernel_vsyscall ()
>> #1  0xf7e7548f in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:55
>> #2  0xf7e76ec0 in __GI_abort () at abort.c:89
>> #3  0xf7eb4f99 in __libc_message (do_abort=do_abort@entry=1, fmt=fmt@entry=0xf7fbaf3f "%s") at ../sysdeps/posix/libc_fatal.c:175
>> #4  0xf7eb4fd4 in __GI___libc_fatal (message=0xf7fbe128 "memory clobbered past end of allocated block\n")
>>     at ../sysdeps/posix/libc_fatal.c:186
>> #5  0xf7ec2570 in mabort (status=MCHECK_TAIL) at mcheck.c:362
>> #6  0xf7ec264b in checkhdr (hdr=hdr@entry=0x5657a018) at mcheck.c:113
>> #7  0xf7ec2c18 in checkhdr (hdr=0x5657a018) at mcheck.c:185
>> #8  freehook (ptr=0x5657a030, caller=0xf7e6c86b <_nl_load_locale_from_archive+1419>) at mcheck.c:186
>> #9  0xf7ec0395 in __GI___libc_free (mem=0x5657a030) at malloc.c:2936
>> #10 0xf7e6c86b in _nl_load_locale_from_archive (category=category@entry=5, namep=namep@entry=0xffffcd9c) at loadarchive.c:190
>> #11 0xf7e6b730 in _nl_find_locale (locale_path=0x0, locale_path_len=0, category=category@entry=5, name=name@entry=0xffffcd9c)
>>     at findlocale.c:154
>> #12 0xf7e6ae51 in __GI_setlocale (category=5, locale=0x80882e4 "") at setlocale.c:417
>> #13 0x0804a428 in ?? ()
>> #14 0xf7e60480 in __libc_start_main (main=0x804a3d0, argc=2, argv=0xffffcfc0, init=0x8088200, fini=0x8088270,
>>     rtld_fini=0x56565ab0 <_dl_fini>, stack_end=0xffffcfbc) at libc-start.c:289
>> #15 0x0804abb7 in ?? ()
>> (gdb)
>>
>> Has anyone seen this? This appears to be new. I'll see if I can track
>> this down to an environment change in my build box (Fedora 21).
>
> I only saw
>
> FAIL: math/test-float

FWIW,

On Ubuntu 14.04 LTS, using system "gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4" and
../configure --prefix=/usr CC='gcc -m32' CXX='g++ -m32' i686-linux-gnu

I couldn't build current trunk (8cf0ac959d318cf113feb1a9ca5d325010bb2124):


make[2]: Entering directory `/glibc-git/libio'
gcc -m32 oldfileops.c -c -std=gnu99 -fgnu89-inline
-fno-stack-protector -O2 -Wall -Werror -Wno-error=undef -Wundef
-Wwrite-strings -fmerge-all-constants -frounding-math -g
-Wstrict-prototypes   -fPIC -Wa,-mtune=i686 -fexceptions
-ftls-model=initial-exec   -U_FORTIFY_SOURCE   -I../include
-I/glibc-git/build32/libio  -I/glibc-git/build32
-I../sysdeps/unix/sysv/linux/i386/i686  -I../sysdeps/i386/i686/nptl
-I../sysdeps/unix/sysv/linux/i386  -I../sysdeps/unix/sysv/linux/x86
-I../sysdeps/i386/nptl  -I../sysdeps/unix/sysv/linux/include
-I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/pthread
-I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv
-I../sysdeps/unix/i386  -I../sysdeps/unix  -I../sysdeps/posix
-I../sysdeps/i386/i686/fpu/multiarch  -I../sysdeps/i386/i686/fpu
-I../sysdeps/i386/i686/multiarch  -I../sysdeps/i386/i686
-I../sysdeps/i386/i486  -I../sysdeps/i386/fpu
-I../sysdeps/x86/fpu/include -I../sysdeps/x86/fpu  -I../sysdeps/i386
-I../sysdeps/x86  -I../sysdeps/wordsize-32
-I../sysdeps/ieee754/ldbl-96  -I../sysdeps/ieee754/dbl-64
-I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754
-I../sysdeps/generic  -I.. -I../libio -I.   -D_LIBC_REENTRANT
-include/glibc-git/build32/libc-modules.h -DMODULE_NAME=libc -include
../include/libc-symbols.h  -DPIC -DSHARED     -D_IO_MTSAFE_IO -o
/glibc-git/build32/libio/oldfileops.os -MD -MP -MF
/glibc-git/build32/libio/oldfileops.os.dt -MT
/glibc-git/build32/libio/oldfileops.os
oldfileops.c: In function ‘_IO_old_file_write’:
oldfileops.c:670:7: error: implicit declaration of function ‘__write’
[-Werror=implicit-function-declaration]
       _IO_ssize_t count = write (f->_fileno, data, to_do);
       ^
cc1: all warnings being treated as errors


The following trivial patch fixes this:


Ok to commit above?

After that, make check:

XPASS: conform/ISO11/complex.h/conform
XPASS: conform/ISO11/stdalign.h/conform
XPASS: conform/ISO11/stdnoreturn.h/conform
FAIL: elf/tst-protected1a
FAIL: elf/tst-protected1b

As far as I understand, the tst-protected1{a,b} are expected to fail
with binutils 2.24-5ubuntu13

Comments

Carlos O'Donell Aug. 5, 2015, 7:15 a.m. UTC | #1 
On 08/01/2015 06:27 PM, Paul Pluzhnikov wrote:
> The following trivial patch fixes this:

LGTM for 2.23, which is now open. Falls under the obvious category
for including a header for a function you use.

c.
 
> diff --git a/libio/oldfileops.c b/libio/oldfileops.c
> index 54789b2..25797c8 100644
> --- a/libio/oldfileops.c
> +++ b/libio/oldfileops.c
> @@ -41,6 +41,7 @@
>  #include <string.h>
>  #include <errno.h>
>  #include <stdlib.h>
> +#include <unistd.h>
>  #ifndef errno
>  extern int errno;
>  #endif
> 
> Ok to commit above?
> 
> After that, make check:
> 
> XPASS: conform/ISO11/complex.h/conform
> XPASS: conform/ISO11/stdalign.h/conform
> XPASS: conform/ISO11/stdnoreturn.h/conform
> FAIL: elf/tst-protected1a
> FAIL: elf/tst-protected1b
> 
> As far as I understand, the tst-protected1{a,b} are expected to fail
> with binutils 2.24-5ubuntu13
> 
>
Paul Pluzhnikov Aug. 5, 2015, 3:46 p.m. UTC | #2 
On Wed, Aug 5, 2015 at 12:15 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 08/01/2015 06:27 PM, Paul Pluzhnikov wrote:
>> The following trivial patch fixes this:
>
> LGTM for 2.23, which is now open. Falls under the obvious category
> for including a header for a function you use.

Hmm, for some reason I can't reproduce this anymore, and unistd.h is
already included indirectly.

I don't understand why that's happening. But it still seems like a
good idea from header hygiene perspective.
Roland McGrath Aug. 6, 2015, 7:55 a.m. UTC | #3 
> Hmm, for some reason I can't reproduce this anymore, and unistd.h is
> already included indirectly.
> 
> I don't understand why that's happening. But it still seems like a
> good idea from header hygiene perspective.

It is definitely correct (and in the "obvious" category) to have each
source file explicitly #include the header that is the canonical declarator
of each symbol that source file uses directly.
Paul Pluzhnikov Aug. 6, 2015, 3:53 p.m. UTC | #4 
On Thu, Aug 6, 2015 at 12:55 AM, Roland McGrath <roland@hack.frob.com> wrote:
>
> > Hmm, for some reason I can't reproduce this anymore, and unistd.h is
> > already included indirectly.
> >
> > I don't understand why that's happening. But it still seems like a
> > good idea from header hygiene perspective.
>
> It is definitely correct (and in the "obvious" category) to have each
> source file explicitly #include the header that is the canonical declarator
> of each symbol that source file uses directly.


committed as 2ba30a182ca50ac07f45ed1f813a85ccafaed85d

Thanks,
diff mbox

Patch

diff --git a/libio/oldfileops.c b/libio/oldfileops.c
index 54789b2..25797c8 100644
--- a/libio/oldfileops.c
+++ b/libio/oldfileops.c
@@ -41,6 +41,7 @@ 
 #include <string.h>
 #include <errno.h>
 #include <stdlib.h>
+#include <unistd.h>
 #ifndef errno
 extern int errno;
 #endif