一个用户提交了一个错误报告,其中我的应用程序在“__fortify_fail()”中出现了段错误。
我知道这与使用 Debian 的“强化”标志构建我的应用程序有关-D_FORTIFY_SOURCE=2 -fstack-protector
。
不幸的是,用户的回溯并没有告诉我太多,而且用户的响应速度不是很快(现在)。
为了更好地了解发生了什么,我想知道__fortify_fail
实际发生了什么。
这个函数通常只是一个错误报告器。glibc 的示例代码是:
extern char **__libc_argv attribute_hidden;
void
__attribute__ ((noreturn))
__fortify_fail (msg)
const char *msg;
{
/* The loop is added only to keep gcc happy. */
while (1)
__libc_message (2, "*** %s ***: %s terminated\n",
msg, __libc_argv[0] ?: "<unknown>");
}
libc_hidden_def (__fortify_fail)
它可以在这里和那里被称为首选强化来源。“设防”本身只是几个运行时检查。函数中的示例用法openat
来自io/openat.c
:
int
__openat_2 (fd, file, oflag)
int fd;
const char *file;
int oflag;
{
if (oflag & O_CREAT)
__fortify_fail ("invalid openat call: O_CREAT without mode");
return __openat (fd, file, oflag);
}
没有设防,O_CREAT
没有模式是可以接受的(这种情况仍然是高度可疑的,它是合法的)。
想想__fortify_fail
printf+abort。
关于您的问题打开心灵感应,我可能会建议用户在用户代码中使用 libc 时遇到一些问题。/lib/x86_64-linux-gnu/libc.so.6(+0xebdf0)[0x7f75d3576df0]
是 libc 中某些运行时检查失败pd[0x49b5c0]
的地方,也是 libc 错误调用的地方。