public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug nptl/3328] New: bogus assertion failure in __pthread_mutex_lock with gcc 4.2
@ 2006-10-10 14:01 christophe at saout dot de
2006-10-10 14:11 ` [Bug nptl/3328] " jakub at redhat dot com
` (2 more replies)
0 siblings, 3 replies; 4+ messages in thread
From: christophe at saout dot de @ 2006-10-10 14:01 UTC (permalink / raw)
To: glibc-bugs
When compiling glibc 2.5 with a gcc 4.2 snapshot (20061007), I'm seeing the
following assertion failure, e.g. in firefox:
galeon: pthread_mutex_lock.c:82: __pthread_mutex_lock: Assertion
`mutex->__data.__owner == 0' failed.
I did some debugging and found out that the assertion is bogus. The reason it
shows up is because gcc move the load of mutex->__data.__owner before calling
lll_mutex_lock. gdb clearly shows that the owner is 0 after successful
aqcuisition of the lock, but the register has the content 0x6 from before
lll_mutex_lock.
Apparently somehow gcc doesn't get it that it should not reorder the loads
around lll_mutex_lock. I'm not sure whether this is a bug in glibc that shows up
with new gcc optimizations or whether this is a bug in gcc 4.2 (I looked through
the bugzilla regressions and didn't identify any such bugs, I haven't seen any
locking problems with gcc 4.2 compiled kernels either).
Please don't shoot me for testing stuff with alpha compilers. If this is indeed
not a glibc bug, I will report it to the gcc people.
Working disassembled code with gcc 4.1.1:
acquiring mutex (lll_mutex_lock):
3d: 31 c0 xor %eax,%eax
3f: b9 01 00 00 00 mov $0x1,%ecx
44: f0 0f b1 0b lock cmpxchg %ecx,(%ebx)
48: 0f 85 ed 05 00 00 jne 63b <_L_mutex_lock_86>
loading and testing owner:
4e: 8b 43 08 mov 0x8(%ebx),%eax
51: 85 c0 test %eax,%eax
53: 0f 85 71 05 00 00 jne 5ca <__pthread_mutex_lock+0x5ca>
-> __assert_fail
Broken code with gcc 4.2:
loading owner:
2f: 8b 53 08 mov 0x8(%ebx),%edx
lll_mutex_lock:
32: 31 c0 xor %eax,%eax
34: b9 01 00 00 00 mov $0x1,%ecx
39: f0 0f b1 0b lock cmpxchg %ecx,(%ebx)
3d: 0f 85 f3 05 00 00 jne 636 <_L_mutex_lock_78>
testing owner (%edx from above!):
43: 85 d2 test %edx,%edx
45: 0f 85 7f 04 00 00 jne 4ca <__pthread_mutex_lock+0x4ca>
-> __assert_fail
--
Summary: bogus assertion failure in __pthread_mutex_lock with gcc
4.2
Product: glibc
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: nptl
AssignedTo: drepper at redhat dot com
ReportedBy: christophe at saout dot de
CC: glibc-bugs at sources dot redhat dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://sourceware.org/bugzilla/show_bug.cgi?id=3328
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug nptl/3328] bogus assertion failure in __pthread_mutex_lock with gcc 4.2
2006-10-10 14:01 [Bug nptl/3328] New: bogus assertion failure in __pthread_mutex_lock with gcc 4.2 christophe at saout dot de
@ 2006-10-10 14:11 ` jakub at redhat dot com
2006-10-10 18:35 ` christophe at saout dot de
2006-10-11 5:33 ` drepper at redhat dot com
2 siblings, 0 replies; 4+ messages in thread
From: jakub at redhat dot com @ 2006-10-10 14:11 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From jakub at redhat dot com 2006-10-10 14:11 -------
lll_mutex_lock is asm volatile with "memory" clobber, so if GCC reorders
stuff around it, it is a GCC bug, not glibc.
So, please preprocess and file a GCC bug instead.
--
http://sourceware.org/bugzilla/show_bug.cgi?id=3328
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug nptl/3328] bogus assertion failure in __pthread_mutex_lock with gcc 4.2
2006-10-10 14:01 [Bug nptl/3328] New: bogus assertion failure in __pthread_mutex_lock with gcc 4.2 christophe at saout dot de
2006-10-10 14:11 ` [Bug nptl/3328] " jakub at redhat dot com
@ 2006-10-10 18:35 ` christophe at saout dot de
2006-10-11 5:33 ` drepper at redhat dot com
2 siblings, 0 replies; 4+ messages in thread
From: christophe at saout dot de @ 2006-10-10 18:35 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From christophe at saout dot de 2006-10-10 18:35 -------
Bug in gcc bugzilla:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29415
--
http://sourceware.org/bugzilla/show_bug.cgi?id=3328
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 4+ messages in thread
* [Bug nptl/3328] bogus assertion failure in __pthread_mutex_lock with gcc 4.2
2006-10-10 14:01 [Bug nptl/3328] New: bogus assertion failure in __pthread_mutex_lock with gcc 4.2 christophe at saout dot de
2006-10-10 14:11 ` [Bug nptl/3328] " jakub at redhat dot com
2006-10-10 18:35 ` christophe at saout dot de
@ 2006-10-11 5:33 ` drepper at redhat dot com
2 siblings, 0 replies; 4+ messages in thread
From: drepper at redhat dot com @ 2006-10-11 5:33 UTC (permalink / raw)
To: glibc-bugs
------- Additional Comments From drepper at redhat dot com 2006-10-11 05:33 -------
gcc bug.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
http://sourceware.org/bugzilla/show_bug.cgi?id=3328
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2006-10-11 5:33 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-10-10 14:01 [Bug nptl/3328] New: bogus assertion failure in __pthread_mutex_lock with gcc 4.2 christophe at saout dot de
2006-10-10 14:11 ` [Bug nptl/3328] " jakub at redhat dot com
2006-10-10 18:35 ` christophe at saout dot de
2006-10-11 5:33 ` drepper at redhat dot com
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).