仅在发布版本中出现程序段错误
Program segfaulting in release version only
我有一个可执行文件在发布 但在调试 中没有。我认为这是对 printf 系列函数的错误调用。
当 运行 我得到这个:
*** buffer overflow detected ***: ./mybin terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777f5)[0x7f3a8914d7f5]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f3a891ef21c]
/lib/x86_64-linux-gnu/libc.so.6(+0x117220)[0x7f3a891ed220]
/lib/x86_64-linux-gnu/libc.so.6(+0x116789)[0x7f3a891ec789]
/lib/x86_64-linux-gnu/libc.so.6(_IO_default_xsputn+0x80)[0x7f3a891516c0]
/lib/x86_64-linux-gnu/libc.so.6(_IO_vfprintf+0xc90)[0x7f3a89123e10]
/lib/x86_64-linux-gnu/libc.so.6(__vsprintf_chk+0x84)[0x7f3a891ec814]
/lib/x86_64-linux-gnu/libc.so.6(__sprintf_chk+0x7d)[0x7f3a891ec76d]
./mybin[0x58b50e]
./mybin(main+0x2f3b)[0x41cfab]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f3a890f6840]
./mybin[0x421969]
======= Memory map: ========
...
7f3a8cd2e000-7f3a8cd34000 rw-p 00000000 00:00 0 Aborted (core dumped)
运行 它在 gdb 中产生最后几行:
#8 0x00007ffff3aa7814 in ___vsprintf_chk (s=0x7fffffffaee0 "Some Text - 777", flags=1, slen=20, format=0x894098 "Some Text - %d",
args=args@entry=0x7fffffffad68) at vsprintf_chk.c:82
#9 0x00007ffff3aa776d in ___sprintf_chk (s=<optimized out>, flags=<optimized out>, slen=<optimized out>, format=<optimized out>) at sprintf_chk.c:31
#10 0x000000000058b50e in ?? ()
#11 0x000000000041cfab in main ()
"Some Text - %d"
来自:
char aCharArr[20];
sprintf(aCharArr, "Some text - %d", anInt);
虽然它可以使用 memset
和 snprintf
,但我以前从未遇到过这些行的问题。 int 始终是一位数字。
我无法使用 nm -CD
找到 0x58b50e
。我还能如何或多或少地查明这一点(除了像我正在做 atm 和 filling the program 和 printf
s 一样返回提交树)?
好吧,事实证明,原始文本(不是 "Some text"
)占了 19 个字符加上 %d
,它“始终”是一个数字。即便如此,char aCharArr[20]
中有 20 个字符,生成的字符数组不是 [=14=]
终止的。
增加 aCharArr
的大小(到 8 的下一个倍数,但那只是我)修复了它并使用 snprintf
代替让我安心。
char aCharArr[24];
memset(aCharArr, '[=10=]', sizeof(aCharArr));
sprintf(aCharArr, "Actual str orig len%d", anInt);
在调试中使用 -O2
在发布中使用也很有帮助,尽管可用的信息已经足够了。
我有一个可执行文件在发布 但在调试 中没有。我认为这是对 printf 系列函数的错误调用。
当 运行 我得到这个:
*** buffer overflow detected ***: ./mybin terminated
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777f5)[0x7f3a8914d7f5]
/lib/x86_64-linux-gnu/libc.so.6(__fortify_fail+0x5c)[0x7f3a891ef21c]
/lib/x86_64-linux-gnu/libc.so.6(+0x117220)[0x7f3a891ed220]
/lib/x86_64-linux-gnu/libc.so.6(+0x116789)[0x7f3a891ec789]
/lib/x86_64-linux-gnu/libc.so.6(_IO_default_xsputn+0x80)[0x7f3a891516c0]
/lib/x86_64-linux-gnu/libc.so.6(_IO_vfprintf+0xc90)[0x7f3a89123e10]
/lib/x86_64-linux-gnu/libc.so.6(__vsprintf_chk+0x84)[0x7f3a891ec814]
/lib/x86_64-linux-gnu/libc.so.6(__sprintf_chk+0x7d)[0x7f3a891ec76d]
./mybin[0x58b50e]
./mybin(main+0x2f3b)[0x41cfab]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf0)[0x7f3a890f6840]
./mybin[0x421969]
======= Memory map: ========
...
7f3a8cd2e000-7f3a8cd34000 rw-p 00000000 00:00 0 Aborted (core dumped)
运行 它在 gdb 中产生最后几行:
#8 0x00007ffff3aa7814 in ___vsprintf_chk (s=0x7fffffffaee0 "Some Text - 777", flags=1, slen=20, format=0x894098 "Some Text - %d",
args=args@entry=0x7fffffffad68) at vsprintf_chk.c:82
#9 0x00007ffff3aa776d in ___sprintf_chk (s=<optimized out>, flags=<optimized out>, slen=<optimized out>, format=<optimized out>) at sprintf_chk.c:31
#10 0x000000000058b50e in ?? ()
#11 0x000000000041cfab in main ()
"Some Text - %d"
来自:
char aCharArr[20];
sprintf(aCharArr, "Some text - %d", anInt);
虽然它可以使用 memset
和 snprintf
,但我以前从未遇到过这些行的问题。 int 始终是一位数字。
我无法使用 nm -CD
找到 0x58b50e
。我还能如何或多或少地查明这一点(除了像我正在做 atm 和 filling the program 和 printf
s 一样返回提交树)?
好吧,事实证明,原始文本(不是 "Some text"
)占了 19 个字符加上 %d
,它“始终”是一个数字。即便如此,char aCharArr[20]
中有 20 个字符,生成的字符数组不是 [=14=]
终止的。
增加 aCharArr
的大小(到 8 的下一个倍数,但那只是我)修复了它并使用 snprintf
代替让我安心。
char aCharArr[24];
memset(aCharArr, '[=10=]', sizeof(aCharArr));
sprintf(aCharArr, "Actual str orig len%d", anInt);
在调试中使用 -O2
在发布中使用也很有帮助,尽管可用的信息已经足够了。