public inbox for glibc-bugs@sourceware.org help / color / mirror / Atom feed
From: "christophe at saout dot de" <sourceware-bugzilla@sourceware.org> To: glibc-bugs@sources.redhat.com Subject: [Bug nptl/3328] New: bogus assertion failure in __pthread_mutex_lock with gcc 4.2 Date: Tue, 10 Oct 2006 14:01:00 -0000 [thread overview] Message-ID: <20061010140122.3328.christophe@saout.de> (raw) 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.
next reply other threads:[~2006-10-10 14:01 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2006-10-10 14:01 christophe at saout dot de [this message] 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
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20061010140122.3328.christophe@saout.de \ --to=sourceware-bugzilla@sourceware.org \ --cc=glibc-bugs@sources.redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).