From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71364 invoked by alias); 29 Jun 2015 09:31:04 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 71327 invoked by uid 89); 29 Jun 2015 09:31:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f52.google.com Received: from mail-pa0-f52.google.com (HELO mail-pa0-f52.google.com) (209.85.220.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 29 Jun 2015 09:31:02 +0000 Received: by paceq1 with SMTP id eq1so102408438pac.3 for ; Mon, 29 Jun 2015 02:31:00 -0700 (PDT) X-Received: by 10.66.249.101 with SMTP id yt5mr30092113pac.116.1435570260266; Mon, 29 Jun 2015 02:31:00 -0700 (PDT) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by mx.google.com with ESMTPSA id af5sm41497626pbc.90.2015.06.29.02.30.58 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Mon, 29 Jun 2015 02:30:59 -0700 (PDT) From: Yao Qi To: Sundar Dev Cc: gdb@sourceware.org Subject: Re: [ARM][GDB] backtrace does not go beyond libc functions References: Date: Mon, 29 Jun 2015 09:31:00 -0000 In-Reply-To: (Sundar Dev's message of "Fri, 26 Jun 2015 18:35:23 -0700") Message-ID: <86y4j2q2sz.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg00091.txt.bz2 Sundar Dev writes: > function like poll(), read(), etc., and I attach a remote gdbserver to > the process and try to get backtrace, all I see is the following 4 > backtrace frames as shown below- > (gdb) bt > #0 0x758b9190 in poll () from /lib/libc.so.6 > #1 0x758b9184 in poll () from /lib/libc.so.6 > #2 0x013df120 in ?? () > #3 0x013df120 in ?? () > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > > And address 0x013df120 is in the heap region in proc//maps (shown > below) of my process- > root@xyz# cat /proc/621/maps > ...... > 01389000-0154e000 rw-p 00000000 00:00 0 [heap] > ...... > The address 0x013df120 in frame #2 is got from frame #1 by unwinding. The unwinding can be wrong, so address 0x013df120 can be wrong too. > I've looked at gdb source code and I know that the version of gdb that I'= m using > (7.6.2) has support to backtrace using ARM unwind tables and frame > pointers (see [1] and [2]). But, even then, all I get from GDB > backtrace is the above shown output. Does anybody here have any > comments and/or suggestions? I don't have much suggestions to give, unless I can reproduce it. GDB tries different unwinders to unwind a certain frame, which means exception table unwinder may be used or may not be used. You can debug GDB to see which unwinder is used, and identify why the bad pc (0x013df120) is got from the unwinding. --=20 Yao (=E9=BD=90=E5=B0=A7)