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 6

Answer 1

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.

Answer 2

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

Answer 4

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.