From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id 8D16C3851C12 for ; Sat, 9 May 2020 10:30:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8D16C3851C12 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49798) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jXMkR-0007YK-3X for gdb@sourceware.org; Sat, 09 May 2020 06:30:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:55342) by fencepost.gnu.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1jXMkQ-0007ri-SS for gdb@gnu.org; Sat, 09 May 2020 06:30:22 -0400 Received: from mail-qk1-x72c.google.com ([2607:f8b0:4864:20::72c]:42219) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jXMkO-0006y7-El for gdb@gnu.org; Sat, 09 May 2020 06:30:22 -0400 Received: by mail-qk1-x72c.google.com with SMTP id b188so4511947qkd.9 for ; Sat, 09 May 2020 03:30:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=lEFzggpCkwK0qyD4thWBweRm3JjecxcV/eDyFFo0zA0=; b=JlCgpMUEOiEAh1fX0WhnRVxDzPagf2wxPUbKngKxIqVz7TkcSWarAdRk2iuoEvIfN5 J5Sa/uFproyzHQeMYCAyRu2Ncc+MLMnY6oTMPCGBhEtgrx3axeaFC6IV94VoYPBOFVp2 CvxS7Lit6B6ZzvBdb2dl/iySTvVqUSY2F7B8NUuAYcHjBckpZzzNw95ecl0MZRwO7ySr +/52dFoDYJr1OYof5PNQSsXF7jS7gkfqiw1QVzKlYm04f4hpGI3P/a2zBJvd5RCyzqPH 1JfOzaM4mkMFWrzFXTowA7XiBGuyf41PRQy+lqzXC71bxpl6gTi0SWCNWbbcUHJw91EB Bh6A== X-Gm-Message-State: AGi0Pua1SdEBcFME8/IxUzkOC6ZYNaqXYkyi13bqnYYL1x0S8lBbmgQq yQ3riVnUxBBgp5tCUgi48xbo5M5c+xjPUA7CoNE= X-Google-Smtp-Source: APiQypKdAhwz55iwxOicgrOtCFtvz7+k9UQulEaSomNJ3Vtx86DlNlewo3ZB9v2voI5DDW5KmBX7UmmHJWgF1jx2p7Y= X-Received: by 2002:a37:49d5:: with SMTP id w204mr6573119qka.335.1589020218273; Sat, 09 May 2020 03:30:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a05:6214:323:0:0:0:0 with HTTP; Sat, 9 May 2020 03:30:17 -0700 (PDT) Received: by 2002:a05:6214:323:0:0:0:0 with HTTP; Sat, 9 May 2020 03:30:17 -0700 (PDT) In-Reply-To: References: <20200506191356.GB2242921@embecosm.com> From: Kunal Chauhan Date: Sat, 9 May 2020 16:00:17 +0530 Message-ID: Subject: Re: Fwd: Help: please help to use gdb and its related terms To: Andrew Burgess , gdb@gnu.org Received-SPF: pass client-ip=2607:f8b0:4864:20::72c; envelope-from=atkunalchauhan@gmail.com; helo=mail-qk1-x72c.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_SOFTFAIL, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2020 10:30:25 -0000 On 8 May 2020 10:24 p.m., "Kunal Chauhan" wrote: 1.Manually unwinding the stack is not clear to me. 2. Also should i compile my binary with debug symbol if yes i have no idea please help . 3 can i check all the things while compiling binary like crash issue memory etc? 4. Can I run my binary with gdb at run time? 5. The best to narrow down the crash , if libraries are not under my control. Thanks Kunal On 7 May 2020 12:43 a.m., "Andrew Burgess" wrote: * Kunal Chauhan via Gdb [2020-05-05 21:39:32 +0530]: > ---------- Forwarded message ---------- > From: "Kunal Chauhan" > Date: 5 May 2020 6:55 p.m. > Subject: Help: please help to use gdb and its related terms > To: > Cc: > > Hi Team, > > Here is some output of gdb I am not understanding . > > #0 0xb66e8ee4 in strlen () from /lib/libc.so.6 > > [Current thread is 1 (LWP 2084)] > > (gdb) bt full > > #0 0xb66e8ee4 in strlen () from /lib/libc.so.6 > > No symbol table info available. You're currently in strlen in libc.so.6 (at address 0xb66e8ee4), but you don't have debug information available, so GDB will have unwound the stack using analysis of the function prologue (instead of using unwind information from the debug info). > > #1 0xb6da3854 in ?? () from /opt/qcom/lib/libcurl.so.4 > > No symbol table info available. The previous frame was somewhere is libcurl.so.4 (at address 0xb6da3854) , though GDB couldn't find a nearby text symbol (that's what the '??' tells us). There's no debug information available for this library either. The '??' could be the result of some really aggressive symbol removal from libcurl, or might indicate that the previous unwind went wrong and you're not really at 0xb6da3854. Again, the stack is going to be unwound using prologue analysis as there's no debug information available. > > #2 0x05b40000 in ?? () > > No symbol table info available. This is starting to look very wrong now (I'm always suspicious of addresses ending with 0000), GDB couldn't identify a function or even a file that claims this address. Again (obviously maybe) no debug information, prologue analysis unwind. > > Backtrace stopped: previous frame identical to this frame (corrupt stack?) > After unwinding GDB got back the same stack pointer and program counter for the previous frame. This most likely means the prologue analysis unwinder is trying to unwind an incorrect location, and is just getting back the same junk each time. GDB prints the above message and stops to avoid going into an endless loop. You should consider installing debug information if possible for libc and libcurl, this might aid the unwinder. It's possible that the prologue analysis unwinder went wrong for your target, you should try manually unwinding the stack (by checking the ABI for your target, and examining the machine state) and see if you agree with GDB. Hope this helps, Thanks, Andrew