Bryan Kadzban wrote: > But from looking at the test code, it doesn't appear to be directly > dealing with any of these __ASSUME_BLAH symbols. It appears to be using > standard pthread_blahblah() functions, so if the test is segfaulting, or > getting the wrong result back, I'd expect that user programs calling the > various pthread APIs would do the same. So I *think* the cause of the > failure is in the implementation of these functions.
Yep, confirmed. (Also, it appears this had been submitted to glibc bugzilla already, but was closed as basically "we won't help you debug our stuff, and we think it's working": http://sources.redhat.com/bugzilla/show_bug.cgi?id=12403 -- I've added lots more info there, and the patch I'm attaching here as well.) The core problem here is a stack imbalance. This was actually broken way back in July of 2009, when this code was added, in both of these changes: http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d979611eb9f18ead1b8da3e956b941545f682565 http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=32c6c342b6bc10396785a4542c22f6f95deca684 The second isn't as big of a problem, since the only thing broken is CFI directives to the assembler (which will break debugging info, but I don't *think* they'll break the code at runtime). But the first, if __ASSUME_PRIVATE_FUTEX is on but __ASSUME_FUTEX_CLOCK_REALTIME is off (which is the state we're seeing), will push a new register onto the stack, and add some local-variable space, at function entry, and will *not* clean these two up at function exit. So the "retq" instruction at the end will jump off into never-never land, to either an address coming from garbage on the stack, or to an address coming from a random other register. I've verified that this patch fixes the problem. This might be possible with sed, but I'm not sure how -- but one or the other of these should be done, I think.
Submitted By: Bryan Kadzban <br...@linuxfromscratch.org>
Date: 2011-01-23
Initial Package Version: 2.12.2
Upstream Status: Submitted Upstream
Origin: Bryan Kadzban
Description: Fix stack cleanup code in pthread rwlock functions, to stop these
functions from crashing if --enable-kernel is between 2.6.22 and
2.6.29 (inclusive). See also
http://sources.redhat.com/bugzilla/show_bug.cgi?id=12403
diff --git a/nptl/sysdeps/unix/sysv/linux/x86_64/pthread_rwlock_timedrdlock.S
b/nptl/sysdeps/unix/sysv/linux/x86_64/pthread_rwlock_timedrdlock.S
index f5d055c..8f3c68c 100644
--- a/nptl/sysdeps/unix/sysv/linux/x86_64/pthread_rwlock_timedrdlock.S
+++ b/nptl/sysdeps/unix/sysv/linux/x86_64/pthread_rwlock_timedrdlock.S
@@ -210,7 +210,7 @@ pthread_rwlock_timedrdlock:
cfi_restore(%r12)
retq
-#ifdef __ASSUME_PRIVATE_FUTEX
+#ifdef __ASSUME_FUTEX_CLOCK_REALTIME
cfi_adjust_cfa_offset(16)
cfi_rel_offset(%r12, 8)
cfi_rel_offset(%r13, 0)
diff --git a/nptl/sysdeps/unix/sysv/linux/x86_64/pthread_rwlock_timedwrlock.S
b/nptl/sysdeps/unix/sysv/linux/x86_64/pthread_rwlock_timedwrlock.S
index 6ed8b49..9aaaeba 100644
--- a/nptl/sysdeps/unix/sysv/linux/x86_64/pthread_rwlock_timedwrlock.S
+++ b/nptl/sysdeps/unix/sysv/linux/x86_64/pthread_rwlock_timedwrlock.S
@@ -192,7 +192,7 @@ pthread_rwlock_timedwrlock:
7: movq %rdx, %rax
-#ifndef __ASSUME_PRIVATE_FUTEX
+#ifndef __ASSUME_FUTEX_CLOCK_REALTIME
addq $16, %rsp
cfi_adjust_cfa_offset(-16)
popq %r14
@@ -207,7 +207,7 @@ pthread_rwlock_timedwrlock:
cfi_restore(%r12)
retq
-#ifdef __ASSUME_PRIVATE_FUTEX
+#ifdef __ASSUME_FUTEX_CLOCK_REALTIME
cfi_adjust_cfa_offset(16)
cfi_rel_offset(%r12, 8)
cfi_rel_offset(%r13, 0)
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
