From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1590 invoked by alias); 17 Mar 2006 15:48:39 -0000 Received: (qmail 1573 invoked by uid 22791); 17 Mar 2006 15:48:37 -0000 X-Spam-Check-By: sourceware.org Received: from 203.197.88.2.ILL-PUNE.static.vsnl.net.in (HELO marvin.codito.net) (203.197.88.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 17 Mar 2006 15:48:35 +0000 Received: from zirakzigil.codito.co.in ([220.225.32.98]) (authenticated bits=0) by marvin.codito.net (8.13.5/8.13.5/Debian-3) with ESMTP id k2HFP3EM000660 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Mar 2006 20:55:03 +0530 Subject: Re: Backtrace doesn't terminate. From: Ramana Radhakrishnan Reply-To: ramana.radhakrishnan@codito.com To: Girish Shilamkar Cc: gdb@sources.redhat.com In-Reply-To: <1142607030.5756.10.camel@krypton> References: <1142607030.5756.10.camel@krypton> Content-Type: text/plain Date: Fri, 17 Mar 2006 15:50:00 -0000 Message-Id: <1142608971.7975.84.camel@localhost.localdomain> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00125.txt.bz2 Hi Girish, You need to submit a testcase and a set of steps that people can use to replicate your problem . I doubt anyone would be able to help you out without that. cheers Ramana On Fri, 2006-03-17 at 20:20 +0530, Girish Shilamkar wrote: > Hi All, > I am using gdb 6.4 on Xscale processor. I found that the backtrace > doesn't terminate for multi-threaded application, it keeps on repeating > the last frame. > This problem was also seen on native gdb. > > (gdb) bt > #0 0x401bf06c in nanosleep () > from /opt/timesys/toolchains/armv5l-linux/armv5l-linux- > debug/lib/libc.so.6 > #1 0x401beeb0 in __sleep (seconds=0) > at ../sysdeps/unix/sysv/linux/sleep.c:137 > #2 0x00008574 in thread_func (not_used=0xbee2fba8) at multithread.c:35 > #3 0x400dc0f0 in pthread_start_thread_event (arg=0xbcbffbe0) at > manager.c:310 > #4 0x400dc0f0 in pthread_start_thread_event (arg=0xbcbffbe0) at > manager.c:310 > #5 0x400dc0f0 in pthread_start_thread_event (arg=0xbcbffbe0) at > manager.c:310 > #6 0x400dc0f0 in pthread_start_thread_event (arg=0xbcbffbe0) at > manager.c:310 > #7 0x400dc0f0 in pthread_start_thread_event (arg=0xbcbffbe0) at > manager.c:310 > #8 0x400dc0f0 in pthread_start_thread_event (arg=0xbcbffbe0) at > manager.c:310 > > On investigating further I found that registers remained unchanged > except sp, for these frames. > > (gdb) fr 3 > #3 0x400dc0f0 in pthread_start_thread_event (arg=0xbcbffbe0) at > manager.c:310 > 310 in manager.c > (gdb) info regi > r0 0x0 0 > r1 0xbcbff960 -1128269472 > r2 0x0 0 > r3 0x1 1 > r4 0x174 372 > r5 0xbcbffbe0 -1128268832 > r6 0x0 0 > r7 0x400f0d6c 1074728300 > r8 0x80 128 > r9 0x400eebc0 1074719680 > r10 0x400ee000 1074716672 > r11 0x0 0 > r12 0x0 0 > sp 0xbcbffb40 -1128268992 > lr 0x400dc0f0 1074643184 > pc 0x400dc0f0 1074643184 > fps 0x0 0 > cpsr 0x60000010 1610612752 > (gdb) fr 4 > #4 0x400dc0f0 in pthread_start_thread_event (arg=0xbcbffbe0) at > manager.c:310 > 310 in manager.c > (gdb) info regi > r0 0x0 0 > r1 0xbcbff960 -1128269472 > r2 0x0 0 > r3 0x1 1 > r4 0x174 372 > r5 0xbcbffbe0 -1128268832 > r6 0x0 0 > r7 0x400f0d6c 1074728300 > r8 0x80 128 > r9 0x400eebc0 1074719680 > r10 0x400ee000 1074716672 > r11 0x0 0 > r12 0x0 0 > sp 0xbcbffbd8 -1128268840 > lr 0x400dc0f0 1074643184 > pc 0x400dc0f0 1074643184 > fps 0x0 0 > cpsr 0x60000010 1610612752 > (gdb) > > Kindly let me know where things might be going wrong. > > Thanks & Regards, > -Girish. >