C++ error on Ms Visual Studio: "Windows has triggered a breakpoint in javaw.exe"

Question

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 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?

Thank you so much!

Answer 1

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.

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.

Answer 2

This unfortunately usually means a memory corruption. Some double freeing of memory, function that should return but doesn't or any other type of undefined behavior.

Your best bet of solving this, unless you have a clue as to where this corruption is, is to use a memory analysis tool.