c - 奇怪的 C 程序行为

Question

我真的有一个奇怪的情况。我正在制作一个 Linux 多线程 C 应用程序，使用涉及 char* 字符串的所有细节内存内容，我陷入了一个非常奇怪的位置。

基本上，发生的情况是，使用 POSIX 线程，我正在读取和写入二维字符数组，但它有异常错误。我向您保证，我已经对他们单独访问的内容进行了广泛的测试，并且他们不读取其他线程的数据，更不用说写给其他人了。当与数组一起使用的最后一个线程更改其数组部分时，它似乎更改了其数组的最后几个字符并将字符放入其中，我不知道它们是如何进入的；主要是打印成黑色菱形问号的东西。

我使用 valgrind 和 GDB，但它们并没有真正帮助。据我所知，一切都应该有效。 Valgrind 告诉我我没有释放所有内容。

我知道这一切听起来很含糊，但这就是它变得奇怪的地方:如果我用电围栏编译我的程序，那么它一切正常。 Valgrind 告诉我我正在释放所有内容并且根本没有内存错误，就像我认为的那样。它绝对完美无缺!

所以，我想我的问题是，为什么我的程序在使用电围栏编译时可以正常运行？

(还有一个附带问题，需要采取哪些步骤来确保 100% 的“线程安全”代码？)

Answer 1

Electric fence 会为您进行的每次分配分配页面，我听说至少有两个页面。它使用操作系统的分页机制来检查分配之外的访问。这意味着如果你想要一个新的 14 字符数组，你最终会得到一个全新的页面来容纳它，比如 8k。大多数页面未使用，但您可以通过观察哪些页面被使用来检测错误访问。我可以想象，由于有这么多额外的空间，如果问题通过了 guard ，你就不会看到错误。

如果您的访问不是错误的，而是由于两个线程未正确锁定而导致的损坏，efence 将不会检测到它。 efence 也可能保留指向已分配内存的指针，从而欺骗 valgrind 报告没有问题。您应该使用 --show-reachable=yes 标志运行 valgrind 并查看运行结束时无人认领的内容。