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

["Carlos O'Donell" <carlos at redhat dot com>]

On 08/01/2015 04:03 PM, H.J. Lu 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
> 
> on Fedora 22.

Could you do me a favour and run valgrind on your build of localedef?

valgrind --leak-check=full --show-leak-kinds=all  $PWD/elf/ld.so --library-path $PWD:$PWD/elf ./locale/localedef --list-archive

The most important thing I see is this:

==20823== Warning: set address range perms: large range [0x809a000, 0x2809a000) (noaccess)
==20823== Invalid read of size 4
==20823==    at 0x496BEF9: _nl_archive_subfreeres (in /home/carlos/scratch/build/glibc-pristine-i686/libc.so)
==20823==    by 0x496BC43: free_mem (in /home/carlos/scratch/build/glibc-pristine-i686/libc.so)
==20823==    by 0x496C3A1: __libc_freeres (in /home/carlos/scratch/build/glibc-pristine-i686/libc.so)
==20823==    by 0x4801528: _vgnU_freeres (in /usr/lib/valgrind/vgpreload_core-x86-linux.so)
==20823==    by 0x48D0CDD: _Exit (_exit.S:29)
==20823==  Address 0x10 is not stack'd, malloc'd or (recently) free'd
==20823== 
==20823== 
==20823== Process terminating with default action of signal 11 (SIGSEGV)
==20823==  Access not within mapped region at address 0x10
==20823==    at 0x496BEF9: _nl_archive_subfreeres (in /home/carlos/scratch/build/glibc-pristine-i686/libc.so)
==20823==    by 0x496BC43: free_mem (in /home/carlos/scratch/build/glibc-pristine-i686/libc.so)
==20823==    by 0x496C3A1: __libc_freeres (in /home/carlos/scratch/build/glibc-pristine-i686/libc.so)
==20823==    by 0x4801528: _vgnU_freeres (in /usr/lib/valgrind/vgpreload_core-x86-linux.so)
==20823==    by 0x48D0CDD: _Exit (_exit.S:29)
==20823==  If you believe this happened as a result of a stack
==20823==  overflow in your program's main thread (unlikely but
==20823==  possible), you can try to increase the size of the
==20823==  main thread stack using the --main-stacksize= flag.
==20823==  The main thread stack size used in this run was 8388608.

This is not actually where it fails in glibc, which detects the failure
earlier via malloc checking.

c.