From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 63782 invoked by alias); 30 Jan 2020 13:38:24 -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 63676 invoked by uid 89); 30 Jan 2020 13:38:23 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=experienced, Depending, installing, spot X-HELO: mail-vs1-f68.google.com Received: from mail-vs1-f68.google.com (HELO mail-vs1-f68.google.com) (209.85.217.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 30 Jan 2020 13:38:20 +0000 Received: by mail-vs1-f68.google.com with SMTP id p14so2054726vsq.6 for ; Thu, 30 Jan 2020 05:38:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HusBgWaXltBew9r5kN3hxJTwjOrlMi5lTxNr5tRdZI4=; b=E8kanJAxBSf9cD2de6T/dcBnnKChzTR5zv+7wGudQiyGbsbnw3Y/CM6atPB4vFLYQF 5e9ZMQJTOWAu7/BlmwfB86hP8r2UMoCCgmENh6q1TtfGP8gj+L7TNmm3A9ct1+d8sBki Jm0JGBF8LzjX9cr0/MID+RIuZifso8KgUkTtaMA5IutNXBcMZ+2QrWCnU2k30lq0bA1M BRLTaHcKlfuU7FEyyE0BusbI1g9pP6Jy8iHYoW0Qs6qhMMH55rHLwWHPY61SfEwhNh0A aseFzAFlGa+4D8c57a73OiyM6hnbyEX1Dn0z5UCOxAYEirHrYGMwRSJAOP19ZKUoCaT5 AYzw== MIME-Version: 1.0 References: In-Reply-To: From: dwk Date: Thu, 30 Jan 2020 13:38:00 -0000 Message-ID: Subject: Re: Backtrace stopped: previous frame identical to this frame (corrupt stack?) To: Abhi Arora Cc: Christian Biesinger , GDB Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2020-01/txt/msg00079.txt.bz2 AFAIK, without debug symbols, GDB relies on heuristics, iteratively examining words on the stack for ones that look like base addresses and return addresses. The message you're getting is when a base address points at itself. it just means lots of pointers to stack variables are stored on the stack, confusing the heuristics because they look like base addresses. But it could all be avoided if debug dwarf unwind information indicates the true size of stack frames (it indicates, at each instruction, how many bytes backwards to look to find the start of the stack frame). Installing debug information will help you understand the current coredump better. You won't have to replicate the crash. GDB will use unwind information to accurately figure out where where return addresses and stack frames are in the coredump. The only case in which you would need to replicate the crash is if you had to recompile the code with debugging information, because the new copy of code could have different stack or code layout (e.g. due to compiler optimizations). If for some reason debugging information is not available, or you want to try this process manually, you can dump the words on the stack (x/20x $sp for 32-bit, x/20gx $sp for 64-bit) and try to spot return addresses (run x/i 0xf00 on suspected addresses). Depending on the structure of your executable, it might be relatively simple to spot return addresses if code occupies specific memory ranges. You can get some additional help from people experienced with reverse engineering. Caveat: I'm a binary analysis person, not familiar with GDB internals. On Thu, Jan 30, 2020, 5:34 AM Abhi Arora wrote: > Any possible help in regards to my questions? > > On Mon, 27 Jan 2020, 8:56 pm Abhi Arora, wrote: > > > I will try to add debug symbols of libcurl and regenerate the crash. > > However, I also want to understand in which positive scenario (,i.e., > > stack is not corrupted) I can get this message and what does that mean? > > > > Consider the last two stack frame in Thread 1: > > > > #5 0x769ec986 in curl_easy_perform () from > > > /opt/iotgw-debug/2.5.3/sysroots/armv7at2hf-neon-fslc-linux-gnueabi/usr/lib/libcurl.so.4 > > #6 0x76eb433e in ?? () > > Backtrace stopped: previous frame identical to this frame (corrupt > stack?) > > > > 1. Does it mean stack frame #6 is similar to stack frame #7 (which is not > > printed?)? And that's why gdb stopped itself at #6 assuming #7 could be > > corrupted? > > 2. Does it compare whole stack frame (all the bytes) with the neighbour > > stack frame? > > 3. Can you please help me with a scenerio when two stack frame can be > > similar (when stack is not corrupted)? > > > > On Mon, Jan 27, 2020 at 7:01 PM Christian Biesinger < > cbiesinger@google.com> > > wrote: > > > >> > >> > >> On Sun, Jan 26, 2020, 17:24 Abhi Arora > wrote: > >> > >>> I am having an application with 16 Thread in ARM board running Linux. > My > >>> problem crashed (Segmentation Fault) and I got the core dump. I was > >>> analyzing it and found out I was getting "Backtrace stopped: previous > >>> frame > >>> identical to this frame (corrupt stack?)" message for each of the > thread > >>> except the "main" thread. > >>> > >>> I have posted backtrace of "main", thread that caused SEGV FAULT and a > >>> thread which was working fine. > >>> > >>> 1. I want to know why this message is coming up? What does this mean? > >>> One possibility is corrupt stack but what other times it can show > up? > >>> Recursive function call? > >>> 2. I am not sure how to get more information from Thread 1. I want to > >>> know > >>> which function has called "curl_easy_perform". I want to get complete > >>> backtrace of Thread 1. I tried to "set $sp = " but looks like I can't > >>> modify the SP. I want someone to help with an article to unstack my > >>> Thread > >>> 1 further. Please advise. > >> > >> > >> You should try to install debug symbols for libcurl. GDB can't always > >> unwind stacks without symbols. > >> > >> FWIW, the stack for thread 5 is complete despite the message (it has > >> start_thread in it). > >> > >> Christian > >> > >> > >>> Thread 5 (LWP 3238): > >>> #0 __libc_do_syscall () at libc-do-syscall.S:48 > >>> #1 0x76ab0b00 in __GI___select (nfds=6, readfds=readfds@entry > >>> =0x7563ac58, > >>> writefds=writefds@entry=0x0, exceptfds=exceptfds@entry=0x0, > >>> timeout=timeout@entry=0x7563ac38) > >>> at > >>> /usr/src/debug/glibc/2.28-r0/git/sysdeps/unix/sysv/linux/select.c:41 > >>> #2 0x004a2ace in Isom::Checksafetybuttons (this=this@entry=0x158f780) > >>> at > >>> > >>> > /home/abhishek/develop/gateway-app/GatewayApp/source/WebServer/isom.cpp:292 > >>> #3 0x004a3834 in StartIsom () at > >>> > >>> > /home/abhishek/develop/gateway-app/GatewayApp/source/WebServer/isom.cpp:592 > >>> #4 0x00486494 in ns_Isom::isom_start_function (ptr=0x0) at > >>> > >>> > /home/abhishek/develop/gateway-app/GatewayApp/source/GatewayAppMain.cpp:646 > >>> #5 0x76cc4afa in start_thread (arg=0xa9c8b261) at > >>> /usr/src/debug/glibc/2.28-r0/git/nptl/pthread_create.c:486 > >>> #6 0x76ab538c in ?? () at ../sysdeps/unix/sysv/linux/arm/clone.S:73 > from > >>> > >>> > /opt/iotgw-debug/2.5.3/sysroots/armv7at2hf-neon-fslc-linux-gnueabi/lib/libc.so.6 > >>> Backtrace stopped: previous frame identical to this frame (corrupt > >>> stack?) > >>> > >>> Thread 2 (LWP 3204): > >>> #0 __libc_do_syscall () at libc-do-syscall.S:48 > >>> #1 0x76cc5b18 in __GI___pthread_timedjoin_ex (threadid=1873773472, > >>> thread_return=0x0, abstime=, block=) > >>> at /usr/src/debug/glibc/2.28-r0/git/nptl/pthread_join_common.c:89 > >>> #2 0x76c40f3a in __gthread_join (__value_ptr=0x0, > __threadid= >>> out>) > >>> at > >>> > >>> > /usr/src/debug/gcc-runtime/7.3.0-r0/arm-fslc-linux-gnueabi/libstdc++-v3/include/arm-fslc-linux-gnueabi/bits/gthr-default.h:668 > >>> #3 std::thread::join (this=this@entry=0x7ebe1784) at > >>> > /usr/src/debug/gcc-runtime/7.3.0-r0/libstdc++-v3/src/c++11/thread.cc:136 > >>> #4 0x00470198 in main (argc=, argv=) at > >>> > >>> > /home/abhishek/develop/gateway-app/GatewayApp/source/GatewayAppMain.cpp:599 > >>> > >>> Thread 1 (LWP 3751): > >>> #0 0x769ec67a in Curl_strncasecompare () from > >>> > >>> > /opt/iotgw-debug/2.5.3/sysroots/armv7at2hf-neon-fslc-linux-gnueabi/usr/lib/libcurl.so.4 > >>> #1 0x769ead58 in Curl_checkheaders () from > >>> > >>> > /opt/iotgw-debug/2.5.3/sysroots/armv7at2hf-neon-fslc-linux-gnueabi/usr/lib/libcurl.so.4 > >>> #2 0x769de8fa in Curl_http () from > >>> > >>> > /opt/iotgw-debug/2.5.3/sysroots/armv7at2hf-neon-fslc-linux-gnueabi/usr/lib/libcurl.so.4 > >>> #3 0x769f0e5c in multi_runsingle () from > >>> > >>> > /opt/iotgw-debug/2.5.3/sysroots/armv7at2hf-neon-fslc-linux-gnueabi/usr/lib/libcurl.so.4 > >>> #4 0x769f1708 in curl_multi_perform () from > >>> > >>> > /opt/iotgw-debug/2.5.3/sysroots/armv7at2hf-neon-fslc-linux-gnueabi/usr/lib/libcurl.so.4 > >>> #5 0x769ec986 in curl_easy_perform () from > >>> > >>> > /opt/iotgw-debug/2.5.3/sysroots/armv7at2hf-neon-fslc-linux-gnueabi/usr/lib/libcurl.so.4 > >>> #6 0x76eb433e in ?? () > >>> Backtrace stopped: previous frame identical to this frame (corrupt > >>> stack?) > >