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.


             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: link
Be 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).