backtrace/2325: wrong back trace on x86_64 when pthread_mutex_lock is the innermost function call. bit mode/kernel version/compiler version are irrelevant

backtrace/2325: wrong back trace on x86_64 when pthread_mutex_lock is the innermost function call. bit mode/kernel version/compiler version are irrelevant

[myan]

>Number:         2325
>Category:       backtrace
>Synopsis:       wrong back trace on x86_64 when pthread_mutex_lock is the innermost function call. bit mode/kernel version/compiler version are irrelevant
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Fri Oct 05 15:48:02 UTC 2007
>Closed-Date:
>Last-Modified:
>Originator:     myan@microstrategy.com
>Release:        unknown-1.0
>Organization:
>Environment:
gdb 6.6
linux 2.4/2.6
gcc 3.2.3/3.4.6
>Description:
gdb print out wrong back trace on x86_64 whenever the innermost frame is in pthread_mutex_lock.

I reported this to RedHat Tech support since we use their AS3 and AS4 distribution. But I don't hear from them after a month they confirmed the issue.

In the example below. gdb shows the following back trace:
(gdb) bt
#0  0x00000035e0c0aecb in __lll_mutex_lock_wait () from /lib64/tls/libpthread.so.0
#1  0x0000007fbffff7d8 in ?? ()
#2  0x0000007fbffff601 in ?? ()
#3  0x00000035e0c07c94 in ?? () from /lib64/tls/libpthread.so.0
#4  0x0000000000000000 in ?? ()

Instead I am expecting something like:
#1 0x00000035e0c0aecb in __lll_mutex_lock_wait () from /lib64/tls/libpthread.so.0
#2 func()
#3 main()
>How-To-Repeat:
$ g++ -g foo.cpp -lpthread
$ gdb a.out
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...
Using host libthread_db library "/lib64/tls/libthread_db.so.1".
(gdb) run
Starting program: a.out
[Thread debugging using libthread_db enabled]
[New Thread 182894178464 (LWP 26416)]
 
Program received signal SIGINT, Interrupt.
[Switching to Thread 182894178464 (LWP 26416)]
0x00000035e0c0aecb in __lll_mutex_lock_wait () from /lib64/tls/libpthread.so.0
(gdb) bt
#0  0x00000035e0c0aecb in __lll_mutex_lock_wait () from /lib64/tls/libpthread.so.0
#1  0x0000007fbffff7d8 in ?? ()
#2  0x0000007fbffff601 in ?? ()
#3  0x00000035e0c07c94 in ?? () from /lib64/tls/libpthread.so.0
#4  0x0000000000000000 in ?? ()
(gdb)
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: text/plain; name="foo.cpp"
Content-Disposition: inline; filename="foo.cpp"

#include <stdio.h>
#include <pthread.h>

pthread_mutex_t gLock = PTHREAD_MUTEX_INITIALIZER;

int gCount = 0;

void func()
{
	pthread_mutex_lock(&gLock);

	gCount++;

	pthread_mutex_unlock(&gLock);
}

int main( int argc, char *argv[] )
{
	pthread_mutex_lock(&gLock);

	func();

	return 0;
}

g++ -g foo.cpp -lpthread
diamond: /home/myan/projects/tmp > gdb a.out
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...
Using host libthread_db library "/lib64/tls/libthread_db.so.1".
(gdb) run
Starting program: /home/myan/projects/tmp/a.out
[Thread debugging using libthread_db enabled]
[New Thread 182894178464 (LWP 26416)]
 
Program received signal SIGINT, Interrupt.
[Switching to Thread 182894178464 (LWP 26416)]
0x00000035e0c0aecb in __lll_mutex_lock_wait () from /lib64/tls/libpthread.so.0
(gdb) bt
#0  0x00000035e0c0aecb in __lll_mutex_lock_wait () from /lib64/tls/libpthread.so.0
#1  0x0000007fbffff7d8 in ?? ()
#2  0x0000007fbffff601 in ?? ()
#3  0x00000035e0c07c94 in ?? () from /lib64/tls/libpthread.so.0
#4  0x0000000000000000 in ?? ()
(gdb)

Re: backtrace/2325: wrong back trace on x86_64 when pthread_mutex_lock is the innermost function call. bit mode/kernel version/compiler version are irrelevant

[Daniel Jacobowitz]

The following reply was made to PR backtrace/2325; it has been noted by GNATS.

From: Daniel Jacobowitz <drow@false.org>
To: myan@microstrategy.com
Cc: gdb-gnats@sources.redhat.com
Subject: Re: backtrace/2325: wrong back trace on x86_64 when
	pthread_mutex_lock is the innermost function call. bit mode/kernel
	version/compiler version are irrelevant
Date: Fri, 5 Oct 2007 12:01:50 -0400

 On Fri, Oct 05, 2007 at 03:43:15PM -0000, myan@microstrategy.com wrote:
 > gdb print out wrong back trace on x86_64 whenever the innermost frame is in pthread_mutex_lock.
 
 The last time I checked this was caused by bogus debugging information
 for __lll_mutex_lock_wait in glibc.  I think it's fixed in current
 snapshots of glibc.
 
 -- 
 Daniel Jacobowitz
 CodeSourcery