From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-28010-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 24173 invoked by alias); 6 Mar 2007 16:42:27 -0000
Received: (qmail 24156 invoked by uid 22791); 6 Mar 2007 16:42:26 -0000
X-Spam-Check-By: sourceware.org
Received: from mx1.mxtelecom.com (HELO puma.mxtelecom.com) (82.110.36.85)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 06 Mar 2007 16:42:20 +0000
Received: from aileron.mxtelecom.com ([192.168.2.120]) 	by puma.mxtelecom.com with esmtp (Exim 4.66) 	(envelope-from <richardv@mxtelecom.com>) 	id 1HOcjy-0006XH-3J 	for gdb@sourceware.org; Tue, 06 Mar 2007 16:42:18 +0000
Message-ID: <45ED99E9.8050404@mxtelecom.com>
Date: Tue, 06 Mar 2007 16:42:00 -0000
From: Richard van der Hoff <richardv@mxtelecom.com>
User-Agent: Thunderbird 1.5.0.7 (X11/20060909)
MIME-Version: 1.0
To:  gdb@sourceware.org
Subject: Backtrace not working from within nanosleep
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2007-03/txt/msg00088.txt.bz2

Hi all,

I have a problem with gdb on my live servers, whereby it doesn't seem
to be able to unwind the stacks of threads which have been interrupted
in nanosleep. Typically I get a backtrace like this:

(gdb) bt
#0  0x41166f56 in nanosleep () from /lib/libc.so.6
#1  0x00000000 in ?? ()
(gdb)

This looks very much like the same problem as
http://sourceware.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gdb&pr=2141; 

and I had hoped that upgrading my glibc would solve the problem, but it
persists.

The stack looks fine - it just looks like gdb can't unwind it. Any ideas
what might be the problem here?

I have:

Linux kernel 2.4.26
GNU gdb 6.6
gcc (GCC) 3.3.4
glibc-2.3.6

The state of the thread is as follows:

(gdb) info registers
eax            0xfffffffc       -4
ecx            0x0      0
edx            0x41168ff4       1091997684
ebx            0xbf5ff588       -1084230264
esp            0xbf5ff570       0xbf5ff570
ebp            0xbf5ff740       0xbf5ff740
esi            0xbf5ff588       -1084230264
edi            0x0      0
eip            0x41166f56       0x41166f56 <nanosleep+70>
eflags         0x282    [ SF IF ]
cs             0x23     35
ss             0x2b     43
ds             0x2b     43
es             0x2b     43
fs             0x0      0
gs             0x0      0
(gdb) disassemble
Dump of assembler code for function nanosleep:
0x41166f10 <nanosleep+0>:       call   0x41162303 <__i686.get_pc_thunk.cx>
0x41166f15 <nanosleep+5>:       add    $0x20df,%ecx
0x41166f1b <nanosleep+11>:      cmpl   $0x0,0x2c70(%ecx)
0x41166f22 <nanosleep+18>:      jne    0x41166f3f <nanosleep+47>
0x41166f24 <nanosleep+20>:      mov    %ebx,%edx
0x41166f26 <nanosleep+22>:      mov    0x8(%esp),%ecx
0x41166f2a <nanosleep+26>:      mov    0x4(%esp),%ebx
0x41166f2e <nanosleep+30>:      mov    $0xa2,%eax
0x41166f33 <nanosleep+35>:      int    $0x80
0x41166f35 <nanosleep+37>:      mov    %edx,%ebx
0x41166f37 <nanosleep+39>:      cmp    $0xfffff001,%eax
0x41166f3c <nanosleep+44>:      jae    0x41166f69 <nanosleep+89>
0x41166f3e <nanosleep+46>:      ret
0x41166f3f <nanosleep+47>:      call   0x4115d890
<__pthread_enable_asynccancel>
0x41166f44 <nanosleep+52>:      push   %eax
0x41166f45 <nanosleep+53>:      mov    %ebx,%edx
0x41166f47 <nanosleep+55>:      mov    0xc(%esp),%ecx
0x41166f4b <nanosleep+59>:      mov    0x8(%esp),%ebx
0x41166f4f <nanosleep+63>:      mov    $0xa2,%eax
0x41166f54 <nanosleep+68>:      int    $0x80
0x41166f56 <nanosleep+70>:      mov    %edx,%ebx
0x41166f58 <nanosleep+72>:      xchg   %eax,(%esp)
0x41166f5b <nanosleep+75>:      call   0x4115d930
<__pthread_disable_asynccancel>
0x41166f60 <nanosleep+80>:      pop    %eax
0x41166f61 <nanosleep+81>:      cmp    $0xfffff001,%eax
0x41166f66 <nanosleep+86>:      jae    0x41166f69 <nanosleep+89>
0x41166f68 <nanosleep+88>:      ret
0x41166f69 <nanosleep+89>:      push   %ebx
0x41166f6a <nanosleep+90>:      call   0x4115d047 <__i686.get_pc_thunk.bx>
0x41166f6f <nanosleep+95>:      add    $0x2085,%ebx
0x41166f75 <nanosleep+101>:     xor    %edx,%edx
0x41166f77 <nanosleep+103>:     sub    %eax,%edx
0x41166f79 <nanosleep+105>:     push   %edx
0x41166f7a <nanosleep+106>:     call   0x4115cf74 <__errno_location@plt>
0x41166f7f <nanosleep+111>:     pop    %ecx
0x41166f80 <nanosleep+112>:     pop    %ebx
0x41166f81 <nanosleep+113>:     mov    %ecx,(%eax)
0x41166f83 <nanosleep+115>:     or     $0xffffffff,%eax
0x41166f86 <nanosleep+118>:     jmp    0x41166f68 <nanosleep+88>
End of assembler dump.

(gdb) x /20 $esp
0xbf5ff570:     0x00000000      0x4116227f      0xbf5ff588      0x00000000
0xbf5ff580:     0xbf5ff638      0x40ddd8f0      0x0000001d      0x3b9aba60
0xbf5ff590:     0x45ed6181      0x000e320a      0x41168ff4      0xbf5ff7b0
0xbf5ff5a0:     0x00000000      0xbf5ff740      0xbf5ff578      0x411621ed
0xbf5ff5b0:     0x00000001      0x80000000      0x00000000      0x411ac9dc
(gdb) x /20 $ebp-0x40
0xbf5ff700:     0x00000000      0x00000000      0x00000000      0x00000000
0xbf5ff710:     0x00000000      0x00000000      0x00000000      0x00000000
0xbf5ff720:     0x00000000      0x00000000      0x00000000      0x00000000
0xbf5ff730:     0x00000000      0x00000000      0x41168ff4      0xbf5ff7b0
0xbf5ff740:     0xbf5ff768      0x4115e429      0xbf5ffbe0      0xbf5ff7b0

0x4116227f is <__pthread_timedsuspend_new+191>;  0x4115e429 is
<pthread_cond_timedwait@GLIBC_2.0+281>.

Thanks in advance for any suggestions.