This is the mail archive of the glibc-bugs@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]

[Bug nptl/19004] New: tst-robust8 fails intermittently on x86_64


https://sourceware.org/bugzilla/show_bug.cgi?id=19004

            Bug ID: 19004
           Summary: tst-robust8 fails intermittently on x86_64
           Product: glibc
           Version: 2.23
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: fweimer at redhat dot com
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---
             Flags: security-

The test machine is an x86_64 machine running the 3.10 kernel from Red Hat
Enterprise Linux 7, two Xeon E5-2450 CPUs with 8 cores each, for a total number
of 32 hardware threads.

I can reproduce this with 2.23 master as of today, but I have trouble getting
proper backtraces because I cannot get GDB to use the right libthread_db, so I
am not completely certain the observation below applies to glibc master.

With the glibc 2.17 in Red Hat Enterprise Linux 7, this pthread_mutex_lock call
blocks indefinitely:

232           for (int n = 0; n < N; ++n)
233             {
234               int e = pthread_mutex_lock (&map[n]);
235               if (e != 0 && e != EOWNERDEAD)

Sometimes, this happens on the first round, sometimes on subsequent rounds.

(gdb) print/x map[n]
$4 = {__data = {__lock = 0x80000000, __count = 0x1, __owner = 0x0, 
    __nusers = 0x0, __kind = 0x90, __spins = 0x0, __list = {__prev = 0x0, 
      __next = 0x0}}, __size = {0x0, 0x0, 0x0, 0x80, 0x1, 
    0x0 <repeats 11 times>, 0x90, 0x0 <repeats 23 times>}, 
  __align = 0x180000000}
(gdb) print/x map[n-1]
$5 = {__data = {__lock = 0x800052b0, __count = 0x1, __owner = 0x7fffffff, 
    __nusers = 0x1, __kind = 0x90, __spins = 0x0, __list = {
      __prev = 0x7ffff7feca20, __next = 0x7ffff7ff8480}}, __size = {0xb0, 
    0x52, 0x0, 0x80, 0x1, 0x0, 0x0, 0x0, 0xff, 0xff, 0xff, 0x7f, 0x1, 0x0, 
    0x0, 0x0, 0x90, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x20, 0xca, 0xfe, 
    0xf7, 0xff, 0x7f, 0x0, 0x0, 0x80, 0x84, 0xff, 0xf7, 0xff, 0x7f, 0x0, 
    0x0}, __align = 0x1800052b0}
(gdb) print/x map[n+1]
$7 = {__data = {__lock = 0x40000000, __count = 0x1, __owner = 0x52b3, 
    __nusers = 0x1, __kind = 0x90, __spins = 0x0, __list = {
      __prev = 0x7ffff7ff8200, __next = 0x7ffff7ff8138}}, __size = {0x0, 
    0x0, 0x0, 0x40, 0x1, 0x0, 0x0, 0x0, 0xb3, 0x52, 0x0, 0x0, 0x1, 0x0, 0x0, 
    0x0, 0x90, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x82, 0xff, 0xf7, 
    0xff, 0x7f, 0x0, 0x0, 0x38, 0x81, 0xff, 0xf7, 0xff, 0x7f, 0x0, 0x0}, 
  __align = 0x140000000}
(gdb) print/x map[n+2]
$8 = {__data = {__lock = 0xc0000000, __count = 0x1, __owner = 0x52ba, 
    __nusers = 0x1, __kind = 0x90, __spins = 0x0, __list = {
      __prev = 0x7ffff7ff8d18, __next = 0x7ffff7ff8250}}, __size = {0x0, 
    0x0, 0x0, 0xc0, 0x1, 0x0, 0x0, 0x0, 0xba, 0x52, 0x0, 0x0, 0x1, 0x0, 0x0, 
    0x0, 0x90, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x18, 0x8d, 0xff, 0xf7, 
    0xff, 0x7f, 0x0, 0x0, 0x50, 0x82, 0xff, 0xf7, 0xff, 0x7f, 0x0, 0x0}, 
  __align = 0x1c0000000}

I don't know enough about futexes to debug this further.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


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