Heap corruption at class constructor when allocated dynamically

Question

I have a problem that I have a really hard time figuring out. The program this happened on is a bit big so I'm going to try to put only the relevant pieces of code hoping it's enough.

This is the code that creates my scene and causes the heap corruption:

tetraRender::Camera cam(600.0f, 800.0f, 0.75f);
_ASSERT(_CrtCheckMemory());
//CORRUPTION HAPPENS IN THE NEXT LINE
    std::shared_ptr<tetraRender::Scene>  scene(new tetraRender::Scene(cam));

until that part of the code no dynamic allocation was done by me. And the constructor of the Scene starts like this:

    tetraRender::Scene::Scene(Camera cam)
{
    _ASSERT(_CrtCheckMemory());
    setCamera(cam);
    light.intensity = 1.0f;

the assert fails, and from what I read the heap memory that is beeing written over is the memory of the scene beeing built.

HEAP CORRUPTION DETECTED: after Normal block (#1735) at 0x000001831FD719A0. CRT detected that the application wrote to memory after end of heap buffer. Normal located at 0x000001831FD719A0 is 624 bytes long.

And looking at the heap:

TetraVisu.exe!tetraRender::Scene 1 624

and:

<0x1831FD719A0> 0x000001831fd719a0 {cam={lookAt={value=0x000001831fd719a0 {{x=1.00000000 y=0.000000000 z=0.000000000 ...}, ...} } ...} ...} 624

I don't know how to debug this because it seems as soon as I allocate this object my heap gets corrupted as soon as the constructor starts. I tried allocating other objects and it goes fine. It appears to happen only with Scene and when I have the member Camera shadowProjection.

I know heap issues are hard to figure out that's why I need someone with a better understanding of C++ than me.

EDIT: Also the Scene and camera objects come from a statically linked library I made, I don't know if this can help.

Possible duplicate: https://stackoverflow.com/questions/4172722/what-is-the-rule-of-three — NathanOliver, Apr 13 '18 at 15:03
@NathanOlivier I don't believe it is since I made sure that when I copy a camera and I modify the copy it has no effect on the original. — florent teppe, Apr 13 '18 at 15:09
So you don't make any copies of your `Scene` class? Please **[edit]** your question with an [mcve] or [SSCCE (Short, Self Contained, Correct Example)](http://sscce.org) — NathanOliver, Apr 13 '18 at 15:10
@NathanOlivier No, I do send a shared_pointer referencing a Scene by copy but it happens after the corruption. I my question I put almost all the code of my program executed up to this point. I create a SFML window a openGL context, a camera and my scene and that's it. Could the corruption come from what the SFML or glew library does? I changed the question to show better where the corruption happens — florent teppe, Apr 13 '18 at 15:13
Why don't you have a `_CrtCheckMemory` call just before the line where you claim the corruption happens, if you're not sure? And if it really happens on that line, the only thing that changed is the `Camera` copy constructor ran, and you haven't shown that. — Useless, Apr 13 '18 at 15:18
@florentt *I made sure that when I copy a camera and I modify the copy it has no effect on the original.* -- How did you make sure of this? The only way to ensure this is to turn off copying at compile-time, so that at compile-time, you get an error. Anything else is just blind faith that copying is not done. — PaulMcKenzie, Apr 13 '18 at 15:18
@Useless I did do that, I removed it to make it more readable. — florent teppe, Apr 13 '18 at 15:19
Right, but that means that no-one reading the question knows whether your assertion about where corruption occurs is well-founded. Anyway, if you really did that and the heap is genuinely fine until your `new Scene` line, the Camera copy ctor is really the only thing that could be causing the problem. — Useless, Apr 13 '18 at 15:21
FYI, an MCVE wouldn't have _any_ of the gl calls unless you know they're relevant (which you can tell by removing them and seeing if the problem is still there). It wouldn't have the weird map #defines, or the _any_ of the Scene members you can remove and still reproduce the problem. It _would_ show the Camera definition if that's required for reproducing the issue though. As it stands no-one is likely to be able to help. — Useless, Apr 13 '18 at 15:29
@Useless The `Camera` and `Light` default constructors also run between those lines. If something isn’t in the constructor’s member initializer list (which isn’t used here) is default initialized. — Daniel H, Apr 13 '18 at 15:29
True. But none of them are shown. In fact none of the code actually executed between the comment and the assert is shown. — Useless, Apr 13 '18 at 15:30
@PaulMcKenzie I made sure of this in the debugger, made a camera, and another one like this cam2 = cam1, and then did cam1.setup(-1,0,0) and check if the values in cam2 changed and it didn't. I did all this at runtime. — florent teppe, Apr 13 '18 at 15:42
You know how you're having to explain and justify all these things in comments because they're not in the question? That's why they should have been in the question in the first place. Seriously, an MCVE would save _everyone_ time. — Useless, Apr 13 '18 at 15:52
"The program this happened on is a bit big so I'm going to try to put only the relevant pieces of code hoping it's enough" - it would be *much* better to reduce your program down to a [mcve]. You might even find the bug in the process of doing so. — Jesper Juhl, Apr 13 '18 at 15:54

score 1 · Accepted Answer · answered Apr 17 '18 at 15:44

Ok, so the question was very far from having the right info for anyone to help. The issue seemed to pop in and out of existance at random. It would seem that it was because of a difference between the headers used to build the library and used to call the objects in the final code. I think this is why the heap was getting corrupted, the size was probably calculated differently.

I don't have the issue anymore so this is probably the reason.

Heap corruption at class constructor when allocated dynamically

1 Answers1