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!

Hendrix

This exception can also happen by simply allocating N slots of data (Of any kind) and actually using M>N slots. Everything compiles, but raises an error when ran. Avner – Chaqueta

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.

Thorma

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.

Rinker

He could also try his luck with Application Verifier – Hyacinthie

Answer 3

I got it! Thanks to you all, I understood it was a problem of memory, and maybe of malloc() In fact, I read here:

The bucket-sizing factor must be a multiple of 8 for 32-bit implementations and a multiple of 16 for 64-bit implementations in order to guarantee that addresses returned from malloc subsystem functions are properly aligned for all data types.

IBM.com:

So, I changed the malloc() sizing in the problem point. I went from:

(int**) malloc (const * sizeof(int))

to:

(int**) malloc (const * sizeof(int64_t))

And now it works!

Thanx a lot!

Hendrix

Neither of your constructs are correct. The general form for invoking malloc is (T*)malloc(count*sizeof(T)). In your specific case, the correct form is (int**)malloc(count*sizeof(int*)). – Deductible

Answer 4

Typically that kind of errors occurs when you trying to access the memory you didn't allocate. Check out all of your allocations (and freeing), especially pointer-to-pointer, and code that can access dinamically allocated memory. In your case size of poiners is 64bit insdead of 32bit, that should be prime cause.

Neile

I think accessing memory you don't own would rather break the runtime with an access violation exception. – Rinker

Process may very well own the memory as unallocated part of a heap, I guess that's what he meant. – Hyacinthie