Heap error in C

I know this is really general, but I get "this" (see below) when I run my .c file in Visual C++ 2008 Express. It happens when I call malloc (). Take my work on this - I dynamically allocate memory properly.

HEAP[Code.exe]: HEAP: Free Heap block 211a10 modified at 211af8 after it was freed Windows has triggered a breakpoint in Code.exe.

This may be due to a corruption of the heap, which indicates a bug in Code.exe or any of the DLLs it has loaded.

This may also be due to the user pressing F12 while Code.exe has focus.

开发者_JAVA技巧The output window may have more diagnostic information.

Why do I get this error? What does this even mean?

---

The error message tells you exactly why you got it:

Free Heap block 211a10 modified at 211af8 after it was freed

You had a heap allocated block that was freed then something wrote to that area of memory. It's not nice to write to a freed block of memory.

---

The error isn't actually happening when you call malloc; that's just when it triggers a free heap scan. The actual error happened somewhere before. You malloced some memory at address 211a10 (that's what malloc returned to you). Then you (or some other lib) freed it. Then later, when you call malloc in debug mode, it scans the whole heap -- as a courtesy to you, the poor programmer. It discovers that somebody (your or some lib you call) wrote over part of that array, specifically at address 211af8, or 0xe8 bytes into the array. So you're either still hanging onto a pointer that's been freed (most likely) and using it, or you're just trashing random memory.

---

In my case, with similar symptoms, the issue was the struct alignment mismatch (/Zp option)

I defined for my code a different struct alignment than external libraries (wxWidgets). However, wxWidgets was built with the makefile, so it was compiled using the defaut /Zp. And wxWidget is statically linked.

You can do that, but if you try to delete a wxWidgets-class object from your code the compiler becomes confused about the exact size of struct members. And when running, you get this message:

HEAP[Code.exe]: HEAP: Free Heap block 211a10 modified at 211af8 after it was freed 
Windows has triggered a breakpoint in Code.exe.

Solution:

• Be sure to use the same "Struct Member Alignment" in all code and libraries.

• Best rule is to define /ZP to use "default" value. In Visual Studio, under Properties C/C++ Code Generation

• MSDN cite: "You should not use this option unless you have specific alignment requirements." See here

• Tip: use #pragma pack if you need to control the alignment in some structs See there

Example:

#pragma pack(1) // - 1 byte alignment 

    typedef union 
    {   
        u64 i;
        struct{             // CUSTOMS.s is used by Folders
            u32  uidx;      // Id, as registered 
            byte isoS, isoT;    // isoS/isoT combination.
            byte udd0, udd1;    // custom values (TBD)
        }s;
    }CUSTOMS;

    struct Header   // exactly 128 bits
    {       
        u32 version;        
        u32 stamp;          // creation time
        CUSTOMS customs;                // properties 
    }

#pragma pack()  // this pragma restores the **default** alignment

*

Hope this explanation helps, because this is not actually a bug in code, but a serious configuration mistake: difficult to detect because it is located in subtle compiler options. Thanks for all,

*

---

I dynamically allocate memory properly.

I think that the problem here is that you unallocate the memory inproperly. What I mean by this is that, you might be trying to use freed memory. Sorry I can't help any further, you could probably add the actual code.

---

Take my work on this - I dynamically allocate memory properly.

But are you sure your buffers are all of the correct size and you free() them properly? Double frees and buffer overflows can easily lead to heap corruption that can cause malloc() to fail in all kind of ways.

If the management structures used internally by malloc() get damaged, it will usually not lead to an error immediately. But later calls to malloc() or free() that try to use these damaged structures will fail do erratic things.

---

Are you using malloc() on an array? Because I think the error just might be you forgetting to allocate an extra memory location at the end -- what happens is it tries to write to that location, which isn't allocated to it, and assumes it's trying to write to a place that has already been freed.