Linux 下棧溢出問題分析解決 *** stack smashing detected *** XXXX terminated
1、利用gdb 或者valgrind 定位到具體的代碼
最近在Linux下調試程序，程序異常終止，具體現象如下
*** stack smashing detected ***: ../out/Load terminated
Aborted (core dumped)
利用GDB調試程序下如下
*** stack smashing detected ***: /wan/2.III-A/out/Load terminated
Thread 10 "Load" received signal SIGABRT, Aborted.
[Switching to Thread 0xb37f9b40 (LWP 10889)]
0xb7fdac31 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7fdac31 in __kernel_vsyscall ()
#1 0xb7c6dea9 in __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#2 0xb7c6f407 in __GI_abort () at abort.c:89
#3 0xb7ca937c in __libc_message (do_abort=1, fmt=0xb7da02c7 "*** %s ***: %s terminated\n") at ../sysdeps/posix/libc_fatal.c:175
#4 0xb7d39708 in __GI___fortify_fail (msg=<optimized out>) at fortify_fail.c:37
#5 0xb7d39698 in __stack_chk_fail () at stack_chk_fail.c:28
#6 0x081a0cb9 in xxxxxxx (stGravDataReport=...) at xxxxxxx.cpp:139
通過gdb 基本上可以定位出代碼行數。
同樣利用valgrind 同樣也可以定位出該問題，具體方法爲：
root@/root# valgrind --tool=memcheck --leak-check=full --show-reachable=yes --trace-children=yes ../out/Load
==10854== Memcheck, a memory error detector
==10854== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==10854== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
==10854== Command: ../out/Load
==10854==
*** stack smashing detected ***: ../out/Load terminated
==10854==
==10854== Process terminating with default action of signal 6 (SIGABRT): dumping core
==10854== at 0x4244EA9: raise (raise.c:54)
==10854== by 0x4246406: abort (abort.c:89)
==10854== by 0x428037B: __libc_message (libc_fatal.c:175)
==10854== by 0x4310707: __fortify_fail (fortify_fail.c:37)
==10854== by 0x4310697: __stack_chk_fail (stack_chk_fail.c:28)
==10854== by 0x81A0CB8: xxxxxxxxxx
(xxxxxxx) (xxxxxxxxxxxxxxx.cpp:139)
==10854== by 0x38303930: ???
分析的棧信息相同。
2、分析產生原因
通過查看代碼可以分析到代碼中使用了不安全的函數 sprintf
再次利用gdb進行問題定位：查看到 是由於sprintf拼接成數組長度過長，導致棧溢出。