Guard Malloc 立即发现 EXC_BAD_ACCESS 错误。为什么不一直使用呢？
我几天来一直在调试臭名昭著的 EXC_BAD_ACCESS 错误。 NSZombieEnabled = YES 没有提供任何内容。每次收到错误时，调用堆栈都不同，每 5 或 6 次运行一次。
我在 Lou Franco 的网站上看到了启用保护 malloc 的提示（现在位于 Xcode 4 的方案编辑器中）： 了解 EXC_BAD_ACCESS。一旦我这样做了，我的程序就在导致这个难以捉摸的错误的确切行上停止了。
根据其描述，guard malloc为每个malloc创建单独的页面，并在释放内存时删除整个页面，从而在访问释放的内存时使程序崩溃。对于一般开发，我为什么不一直守护 malloc 呢？它似乎很容易捕获某些类型的内存错误。如果我没有专门测试内存管理或性能，那么使用它是否有一些缺点？
I have been debugging the infamous EXC_BAD_ACCESS error for a few days now. NSZombieEnabled = YES did not offer anything. The call stack was different everytime I received the error, which was once every 5 or 6 runs.
I saw a tip for enabling guard malloc (which is in the scheme editor now for Xcode 4) on Lou Franco's website: Understanding EXC_BAD_ACCESS. As soon as I did this, my program halted on the exact line that was causing this elusive error.
According to its description, guard malloc creates separate pages for every malloc and deletes the whole page when the memory is freed, thus crashing the program when the freed memory is accessed. For general development, why wouldn't I just keep guard malloc on all the time? It seems to catch certain types of memory errors easily. If I'm not testing memory management or performance specifically, is there some downside to using it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
它不仅浪费地址空间，而且会显着减慢你的程序速度（可能会达到无法使用的程度，即使在模拟器上也是如此）。我想对于一个 iOS 程序，当你在模拟器上运行它时，它有点没有实际意义（内存不是问题，而且性能影响也不可怕），但也许以最佳实践的名义，你不应该这样做不断地运行它。
Not only does it waste address space, but it will significantly slow down your program (potentially to the point where it's unusable, even on the simulator). I suppose for an iOS programme when you're running it on the simulator it's a bit moot (memory isn't a problem, and the performance hit isn't terrible either), but perhaps in the name of best practice you shouldn't run it constantly.
为每个
malloc()分配几个字节的整个 4K 页会很快浪费地址空间。Allocating a whole 4K page for a couple bytes per
malloc()wastes address space very quickly.GuardMalloc 确实会使应用程序运行速度变慢，尤其是在正常执行过程中有大量分配时。我大部分时间都将其关闭。
我打开 GuardMalloc 来调试导致堆栈损坏的崩溃。通常，这些 objc_msgSend 位于堆栈左侧的顶部。
使用 GuardMalloc，可以防止悬空指针的随机影响。指针中的地址无法重复使用，并且其内存位置无效。崩溃几乎会立即发生，早在堆栈损坏之前。这对于 C++ 遗留代码以及新的 Objective-C 来说非常有用。
我确实将其他内存调试辅助工具保留为全职。
GuardMalloc does make an app run much slower, especially if you have a large number of allocations during the normal course of execution. I keep it turned off most of the time.
I turn GuardMalloc on to debug a crash that mangles the stack. Often, these have objc_msgSend at the top of whatever is left of the stack.
With GuardMalloc, the random effects of dangling pointers are prevented. The address in the pointer cannot be re-used and its memory location is made invalid. The crash will happen almost immediately, well before the stack is corrupted. This is great for C++ legacy code as well as new Objective-C.
I do leave the other memory debugging aids on full-time.