【问题标题】:gcc address sanitizer core dump on errorgcc地址清理程序核心转储出错
【发布时间】:2017-07-24 12:40:51
【问题描述】:

我正在尝试在服务器上对我怀疑与缓冲区溢出有关的问题进行一些调试,因此我尝试使用 -fsanitize=address 编译我的代码以启用地址清理。

它编译,生成的软件运行。但是,当地址清理程序检测到错误时,我会尝试获取核心转储,因为由于设置,这几乎是我从系统中获取信息的唯一方法。

我在命令行上调用带有ASAN_OPTIONS=abort_on_error=1 的软件(使用shell 脚本来执行此操作),并检查了ulimit -c 是否提供了无限的结果,但它不会产生核心转储。

我错过了什么?

这是在具有 gcc 版本 4.8.4 的 ubuntu 14.04 服务器上

编辑:sysctl kernel.core_pattern 回馈kernel.core_pattern = |/usr/share/apport/apport %p %s %c %P。这可能意味着启用了 apport(至少以某种形式)。但是,我已经能够从软件中的断言和 SIGFPE 中获得该系统上正确的核心文件(这就是数组溢出的嫌疑来源)。

【问题讨论】:

  • 你启用apport了吗? kernel.core_patternsysctl 的值是多少?

标签: gcc core address-sanitizer


【解决方案1】:

让我猜猜,这是 x64 目标吗?那里禁用了核心转储以避免转储 16 TB 影子内存(有关详细信息,请参阅文档disable_coredumphere)。

较新版本的 GCC/Clang remove shadow from core by default 可以做类似的事情

export ASAN_OPTIONS=abort_on_error=1:disable_coredump=0

但恐怕 4.8 太旧了。

作为替代建议,为什么回溯对您来说还不够?如果您无权访问程序stderr,则可以使用log_pathlog_to_syslog 来保留它们。

注意:我 posted suggestion 在所有平台上启用核心转储。

【讨论】:

    猜你喜欢
    • 2020-09-08
    • 1970-01-01
    • 2023-04-11
    • 2019-02-07
    • 2013-05-04
    • 2019-01-14
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多