* Backtrace stopped: previous frame identical to this frame (corrupt stack?)
@ 2020-01-26 16:24 Abhi Arora
2020-01-27 13:31 ` Christian Biesinger via gdb
0 siblings, 1 reply; 5+ messages in thread
From: Abhi Arora @ 2020-01-26 16:24 UTC (permalink / raw)
To: gdb
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.
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?)
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Backtrace stopped: previous frame identical to this frame (corrupt stack?)
2020-01-26 16:24 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Abhi Arora
@ 2020-01-27 13:31 ` Christian Biesinger via gdb
2020-01-27 15:26 ` Abhi Arora
0 siblings, 1 reply; 5+ messages in thread
From: Christian Biesinger via gdb @ 2020-01-27 13:31 UTC (permalink / raw)
To: Abhi Arora; +Cc: gdb
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?)
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Backtrace stopped: previous frame identical to this frame (corrupt stack?)
2020-01-27 13:31 ` Christian Biesinger via gdb
@ 2020-01-27 15:26 ` Abhi Arora
2020-01-30 10:34 ` Abhi Arora
0 siblings, 1 reply; 5+ messages in thread
From: Abhi Arora @ 2020-01-27 15:26 UTC (permalink / raw)
To: Christian Biesinger; +Cc: gdb
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?)
>>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Backtrace stopped: previous frame identical to this frame (corrupt stack?)
2020-01-27 15:26 ` Abhi Arora
@ 2020-01-30 10:34 ` Abhi Arora
2020-01-30 13:38 ` dwk
0 siblings, 1 reply; 5+ messages in thread
From: Abhi Arora @ 2020-01-30 10:34 UTC (permalink / raw)
To: Christian Biesinger; +Cc: gdb
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?)
>>>
>>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Backtrace stopped: previous frame identical to this frame (corrupt stack?)
2020-01-30 10:34 ` Abhi Arora
@ 2020-01-30 13:38 ` dwk
0 siblings, 0 replies; 5+ messages in thread
From: dwk @ 2020-01-30 13:38 UTC (permalink / raw)
To: Abhi Arora; +Cc: Christian Biesinger, GDB
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 <engr.abhiarora@gmail.com> wrote:
> 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?)
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-01-30 13:38 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-26 16:24 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Abhi Arora
2020-01-27 13:31 ` Christian Biesinger via gdb
2020-01-27 15:26 ` Abhi Arora
2020-01-30 10:34 ` Abhi Arora
2020-01-30 13:38 ` dwk
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).