This is the mail archive of the libc-help@sourceware.org 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]

Help debugging x86_64 futex bug


Hi,

I am getting testsuite failures with the current glibc master HEAD using gcc-4.5.2, binutils-2.21 and linux-2.6.36.2 on x86_64-unknown-linux-gnu. I do not get this issue on i686-pc-linux-gnu.

The following fail:
make[2]: *** [/build/glibc-build/nptl/tst-rwlock6.out] Error 1
make[2]: *** [/build/glibc-build/nptl/tst-rwlock7.out] Error 1
make[2]: *** [/build/glibc-build/nptl/tst-rwlock9.out] Error 1
make[2]: *** [/build/glibc-build/nptl/tst-rwlock11.out] Error 1
make[2]: *** [/build/glibc-build/nptl/tst-rwlock12.out] Error 11
make[2]: *** [/build/glibc-build/nptl/tst-rwlock14.out] Error 1
make[2]: *** [/build/glibc-build/nptl/tst-abstime.out] Error 1

with error message:
Didn't expect signal from child: got `Segmentation fault'

With glibc configured with:
../glibc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --with-headers=/usr/include --enable-add-ons=nptl,libidn --enable-kernel=2.6.27 --with-tls --with-__thread --enable-bind-now --without-gd --without-cvs --disable-profile --disable-multi-arch


I noticed that I do not get these errors with --enable-kernel-2.6.18 or --enable-kernel-2.6.36. Bisecting which kernel versions fail gives:

Good: 2.6.18, 2.6.20, 2.6.21
Bad: 2.6.22, 2.6.27, 2.6.28
Good: 2.6.29, 2.6.30, 2.6.32, 2.6.36

Looking in sysdeps/unix/sysv/linux/kernel-features.h at what is enabled at the boundary points:
Support for utimensat syscall was added in 2.6.22
Support for private futexes was added in 2.6.22
Support for the FUTEX_CLOCK_REALTIME flag was added in 2.6.29.
Support for the AT_RANDOM auxiliary vector entry was added in 2.6.29


The two futex changes look obvious contenders. I can confirm this by building with --enable-kernel=2.6.27 and manually adjusting the relevant futex defines:

Bad (default - 2.6.22 - 2.6.28):
# define __ASSUME_PRIVATE_FUTEX	1
# undef __ASSUME_FUTEX_CLOCK_REALTIME

Good (default pre 2.6.22):
# undef __ASSUME_PRIVATE_FUTEX
# undef __ASSUME_FUTEX_CLOCK_REALTIME

Good (default 2.6.29 and later):
# define __ASSUME_PRIVATE_FUTEX	1
# define __ASSUME_FUTEX_CLOCK_REALTIME	1


Generating a list of files that have #ifdef/#ifndef on both these values (assuming this is not some complex interaction at the moment) and are x86_64 specific (as this does not occur on i686 builds) gives:


nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S
nptl/sysdeps/unix/sysv/linux/x86_64/lowlevelrobustlock.S
nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_timedwait.S
nptl/sysdeps/unix/sysv/linux/x86_64/pthread_rwlock_timedrdlock.S
nptl/sysdeps/unix/sysv/linux/x86_64/pthread_rwlock_timedwrlock.S

If we further assume that the bug requires a nested #ifdef for these two values, that restricts the issue to small parts of the last three files.


Any suggestions on how to further trace this issue?


Thanks,
Allan


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