Re: Backtrace stopped: previous frame identical to this frame (corrupt stack?)

[Abhi Arora <engr.abhiarora@gmail.com>]

Any possible help in regards to my questions?

On Mon, 27 Jan 2020, 8:56 pm Abhi Arora, <engr.abhiarora@gmail.com> 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 <engr.abhiarora@gmail.com> 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=<optimized out>, block=<optimized out>)
>>>     at /usr/src/debug/glibc/2.28-r0/git/nptl/pthread_join_common.c:89
>>> #2  0x76c40f3a in __gthread_join (__value_ptr=0x0, __threadid=<optimized
>>> 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=<optimized out>, argv=<optimized out>) 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?)
>>>
>>