Ms Visual Studio 上的 C++ 错误:“Windows 已触发 javaw.exe 中的断点"；
我一直致力于我的软件 C++ &Java(使用 Microsoft Visual Studio 2008 和 Eclipse 构建)，我一直在尝试将其从 32 位系统转移到 64 位系统.
I've been always working on my software C++ & Java (build with Microsoft Visual Studio 2008 & Eclipse), and I've been trying to move it from a 32-bit system to a 64-bit one.
编译阶段没问题，但在执行时我收到一条错误消息:
The compilation phase is alright, but on execution I get an error that says:
"Windows 在 javaw.exe 中触发了断点.这可能是由于堆损坏，这表明 javaw.exe 或任何它已加载的 DLL-.这也可能是由于用户在 javaw.exe 具有焦点时按了 F12.输出窗口可能有更多的诊断信息.[BREAK] [继续] [忽略]"
"Windows has triggered a breakpoint in javaw.exe. This may be due to corruption of the heap, which indicates a bug in javaw.exe or any of the DLLs it has loaded-. This may also be due to user pressing F12 while javaw.exe has focus. The output window may have more diagnostic information. [BREAK] [CONTINUE] [IGNORE]"
您可以在此处查看错误快照:
You can see a snapshot of the error here:
你知道这个错误意味着什么吗?堆损坏"是什么意思?你以前有过这种错误的经历吗?
Have you any idea of what this error means? What does "corruption of the heap" mean? Have you evere had any experience with this kind of error before?
非常感谢！
推荐答案
这是 Windows 堆分配器的一个非常好的特性，从 Vista 开始可用.它告诉你你的代码有一个指针错误.好吧，希望是你的代码而不是 JVM 有错误:) 你最好假设它是你的代码.
It is a very nice feature of the Windows heap allocator, available since Vista. It tells you that your code has a pointer bug. Well, hopefully it is your code and not the JVM that has the bug :) You'd better assume it is your code.
实际原因介于轻微之间，比如试图释放已经从另一个堆释放或分配的内存(当你与另一个程序互操作时并不少见)，到非常讨厌，比如通过溢出将堆提前炸成碎片堆分配的缓冲区.
The actual cause ranges somewhere between mild, like trying to free memory that was already freed or allocated from another heap (not uncommon when you interop with another program), to drastically nasty, like having blown the heap to pieces earlier by overflowing a heap allocated buffer.
诊断的粒度不够细，无法准确地告诉您出了什么问题，只是出了点问题.您通常通过仔细的代码审查和人为地禁用代码块来追踪它，直到错误消失.这就是显式内存管理的乐趣.如果 32 位版本是干净的(检查它)，那么由于对指针大小的假设，这可能与 64 位代码相关联.64 位指针不适合 int 或 long，因此它会被截断.使用截断的指针值将触发此断言.这是令人愉快的问题，您会在调用堆栈"窗口中找到故障代码.
The diagnostic is not fine-grained enough to tell you exactly what went wrong, just that there's something wrong. You typically chase it down with a careful code review and artificially disabling chunks of code until the error disappears. Such are the joys of explicit memory management. If the 32-bit version is clean (check it) then this can be associated with 64-bit code due to assumptions about pointer size. A 64-bit pointer doesn't fit in an int or long, so it is going to get truncated. And using the truncated pointer value is going to trigger this assert. That's the happy kind of problem, you'll find the trouble code back in the Call Stack window.
相关文章