你认为你的chroot是受版本控制的，而实际上并不是。
我在分析在我无法访问的linux机器上生成的崩溃转储时遇到了一个问题。情况如下:
- 开发发生在运行Ubuntu 14.04、13.10和14.04等发行版的Linux机器上。
- 目标是一个基于嵌入式x86的系统，运行在一个剥离的下载Debian 5
- 目标的构建发生在一台开发机器上，取决于谁发布。我们使用一个chroot环境来进行交叉构建，我们非常确定chroot环境是相同的(版本通过git控制)
顺便说一下，软件是用c++编写的。
现在时不时的软件崩溃的情况下，我们无法重现，所以我们的用户通过电子邮件发送给我们一个核心文件。计划如下:
- 从chroot-environment 中使用debug符号编译相同版本的软件
- 使用GDB查看核心文件，也在chroot环境中。
这通常工作得很好，除了一个问题。只有当调试发生在构建剥离和发布的二进制文件的同一台机器上时，它才有效。在其他机器上，调试器似乎会感到困惑，堆栈跟踪可能由完全不相关的调用组成，这些调用没有任何意义。这是一件我们思考了一段时间却没有结论的事情。而且这是一个我们可以轻松处理的情况。
但是随后在我的机器上发生了一些无意识的升级到一个新的发行版，渲染了所有来自目标的核心文件，我为它们构建了无用的…
现在我正在寻找一种方法来(a)了解正在发生的事情和(b)一种方法来交叉调试核心文件，这些文件在没有远程访问运行不同Linux发行版的可能性的机器上生成。哦，第三，如果我们可能做了一些根本性的错误?
只有当调试发生在同一台机器上时，剥离的和发布的二进制文件才有效。
(a)理解发生了什么
很明显，尽管你相信你有一个封闭的构建环境，你实际上并没有。如果你有一个完全封闭的构建环境，在另一台机器上构建也没关系。
因此，您的第一步应该是找到并消除所有非密封的东西，直到您可以在构建您的版本的每台机器上构建位相同的版本。
一旦你做到了这一点，它也应该解决你的(b)问题。
(c)如果我们可能正在做一些根本错误的事情?