macOS调用abort()触发陷阱却无core dump生成的原因问询

嘿，我来帮你理清这个问题——你遇到的差异其实是macOS和Linux系统在信号处理、core dump机制上的固有区别，还有Apple LLVM（也就是你以为的gcc）和Linux下GCC的行为差异，具体原因和解决方法如下：

1. 为什么输出是Abort trap: 6而不是Abort (core dumped)？ #

这是系统层面的实现差异：

• Linux的abort()函数在发送SIGABRT信号时，会向stdout输出标准的Abort (core dumped)提示
• 而macOS的abort()实现不同，它会输出Abort trap: 6，其中6是SIGABRT信号的编号（你可以用kill -l查看所有信号的编号对应关系），这是macOS的正常输出，不用疑惑。

2. 为什么没有生成core文件？ #

macOS默认关闭了core dump的生成功能，这和你程序的文件权限（0777）无关，需要手动开启：

• 临时开启（仅当前终端会话有效）：
  在终端执行以下命令：

  ulimit -c unlimited
  

• 永久开启（所有终端会话生效）：
  根据你使用的shell，编辑对应的配置文件：

  • 如果你用bash：编辑~/.bash_profile，添加一行ulimit -c unlimited
  • 如果你用zsh：编辑~/.zshrc，添加一行ulimit -c unlimited
    保存后重启终端，或者执行source ~/.bash_profile（或source ~/.zshrc）让配置立即生效。

  开启后，core文件会默认生成在/cores目录下，文件名格式为core.<进程PID>，你可以用ls /cores查看是否生成。

3. 关于编译器的小说明 #

你看到的/usr/bin/gcc确实是Apple LLVM（clang）的别名，这是macOS的默认设置——Apple用clang替代了GCC，但保留了gcc命令作为兼容入口。不过这个差异对你的abort()行为影响不大，核心问题还是macOS的系统机制和Linux不同。

验证步骤 #

1. 在终端执行ulimit -c unlimited
2. 重新编译并运行你的程序：

   gcc test.c -o test
   ./test
   

3. 执行ls /cores，就能看到对应PID的core文件了。

内容的提问来源于stack exchange，提问作者campovski