当 std::vector 存在时,强指针会导致应用程序关闭时堆损坏
我在应用程序关闭期间遇到奇怪的堆损坏错误,如果我的代码中存在“std::vector”,并且我删除了我的“ref_count”变量。如果我没有 std::vector,则不会发生崩溃。如果存在 std::vector 并且我不删除 ref_count (导致内存泄漏),则会发生堆崩溃。我的测试用例尽可能小,但不幸的是它太大了,所以它位于 http://codepad .org/USIPjPHJ。有人对可能出现的问题有什么建议吗?
在我的输出窗口中,我会因堆异常而崩溃。
HEAP[CrashTest.exe]:HEAP:释放堆块 6d4c30 在释放后于 6d4c58 进行修改 Windows 在 CrashTest.exe 中触发了断点。
这可能是由于堆损坏造成的,这表明 CrashTest.exe 或其加载的任何 DLL 中存在错误。
这也可能是由于用户在 CrashTest.exe 获得焦点时按了 F12。
输出窗口可能有更多诊断信息。
我的 IDE 是 Visual Studio 2010 SP1(也尝试过非 SP1),但这应该不会导致问题。
I am getting a strange heap corruption error during the application close where if a "std::vector" is present in my code, AND I am deleted my "ref_count" variable. If I don't have an std::vector, there is no crash. If there is a std::vector and I don't delete the ref_count (causing a memory leak), then there is a heap crash. I am made my test case as small as possible, but unfortunately it is too big for here so it is located at http://codepad.org/USIPjPHJ . Does anyone have any suggestions on what could be the problem?
I will get a crash with the heap exception of this in my output windows.
HEAP[CrashTest.exe]: HEAP: Free Heap block 6d4c30 modified at 6d4c58 after it was freed
Windows has triggered a breakpoint in CrashTest.exe.
This may be due to a corruption of the heap, which indicates a bug in CrashTest.exe or any of the DLLs it has loaded.
This may also be due to the user pressing F12 while CrashTest.exe has focus.
The output window may have more diagnostic information.
My IDE is Visual Studio 2010 SP1 (tried on non SP1 also) but that should not be causing the issue.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
这一行:
将 *ref_count 设置为 0(因为 ptr == NULL),然后这一行:
将 *ref_count 递增到 1。
退出时,析构函数被调用两次(一次用于 reg1,一次用于 copy1)。第一次,*ref_count 减为 0,并且 ref_count 被释放,第二次留下悬空引用。
This line:
sets *ref_count to 0 (because ptr == NULL), then this line:
increments *ref_count to 1.
On exit, the destructor is called twice (once for reg1, once for copy1). The first time, *ref_count is decremented to 0 and ref_count is deallocated, leaving a dangling reference for the second time.