程序在 make 启动时运行，但不是通过 shell，为什么？答案

【问题标题】：Program runs when launched by make, but not via shell, why?程序在 make 启动时运行，但不是通过 shell，为什么？
【发布时间】：2009-03-19 19:13:44
【问题描述】：

我编写了一个 C 程序，在其中我做了一些相当繁重的堆栈分配，大约 2 MiB。由于我使用的是穷人的 IDE*，所以每次编译时，我都会通过 make 自动运行程序以对其进行测试。

我几乎把所有东西都打包好了，但由于某种原因，在最后的一些优化过程中，我直接从 shell 运行它。即时段错误！使用 make 运行它仍然有效，而手动运行它总是会产生相同的段错误。

我最终将我正在执行的堆栈分配量减少到 256 KiB，从而解决了这个问题。我的理由是 make 可能正在执行该进程，因此它继承了一些奇怪的参数，使其能够使用更多的堆栈空间。

虽然现在一切都很好，但我无法测试我的理论。任何人都可以确认或否认，或建议某种测试方式吗？

* zsh、vim、gcc、gdb 和一些疯狂的 makefile

【问题讨论】：

标签： c debugging unix makefile

【解决方案1】：

您可以尝试使用ulimit(1) 设置最大堆栈大小，看看是否有效：

# Limit stack to 1024 KiB
ulimit -s 1024; ./myprogram
# Now no limit
ulimit -s unlimited; ./myprogram

【讨论】：

是的，做到了！它在 'ulimit -s unlimited' 之后直接从 shell 工作。伙计，对于成熟的 make 程序来说，这似乎是一个严重的错误。（我正在使用 gmake 3.81）我想我会给他们写一封友好的电子邮件:-)
我不认为这是 make 的错误，因为它只在 make 之外失败：make 可能出于其邪恶目的将 ulimit 设置为高（或无限）值，这是由其继承的子流程。
@pax，同意。但是，在我看来，改变子进程继承的环境仍然是一个错误。人们一直在做诸如“make test”之类的事情，并期望他们正在运行 make 的事实不会影响任何事情。

【解决方案2】：

就我个人而言，我的第一步是尝试使用 gdb 或调试 printfs 或其他任何方式定位代码中发生段错误的位置。（这就是为什么您总是检查 malloc 的返回值的原因，它减少了可能的段错误来源；-p）一方面，找到问题的确切来源可以为您提供支持或反对您的堆栈分配理论的证据；此外，它还可以让您插入错误检查代码，以便程序可以优雅地退出并显示信息丰富的错误消息而不是段错误。

【讨论】：

【解决方案3】：

需要更多信息来诊断此问题。也就是说，很高兴看到您正在使用的 makefile 和 shell 脚本。

【讨论】：