Problem appearing in Release mode (Not external symbols err)

[s3rius]

Hi there,
For a little while now I get an error when running my program in Release mode instead of debug.
When I close the application I get the following error:

Windows has triggered a breakpoint in SFMLTest.exe.

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

I already figured out that this happens when I try to delete a pointer in one of my classes.

My main looks about like that:

Code: [Select]


void main(){

Global::levelMap=new LevelMap("res\\l3.lmap");
...lots of uninteresting code code...
delete Global::levelMap; <-- causing the error

}


The destructor of LevelMap is:

Code: [Select]


LevelMap::~LevelMap(){
for (int i = 0; i < w; ++i)
delete[] map[i];
..also some other code..
}


It destroys a 2d array. When I comment out this part I don't get the above error anymore.
However:

1) The code doesn't make any problems in Debug mode.

2) I tried to insert a break point into the destructor to check the variables. In Debug mode that's no problem. In Release mode the breakpoint won't trigger. MSVC gives me the following hint about the breakpoint:

The breakpoint will not currently be hit. No executable code is associated with this line.
Possible causes include: prepocessor directives or compiler/linker optimizations.

3) Even though the dtor doesn't seem to be executed at all removing the

Code: [Select]

delete[] map[i] also removes the error.

4) Release Mode worked fine a while ago and I haven't changed anything in the Project settings since then.

The error message suggests that some optimization option messes with it. I don't know anything about those though, so I'm pretty much in the dark.

Can anyone help me shed some light on things?

[Laurent]

Extract a minimal code that reproduces the problem from your whole project. You have 99% probability to find the error by doing this. Then if you still can't find it, we'll be able to test this minimal code quickly and tell you what's wrong.

But first make sure that you're linking to SFML release libraries, not debug ones

[s3rius]

Alright, here we go:

Main.cpp

Code: [Select]

#include "LevelMap.h"

int main(){

LevelMap p;

    return EXIT_SUCCESS;
}

LevelMap.h:

Code: [Select]

class LevelMap
{
private:
unsigned char w; //width of map
unsigned char h; //height of map
unsigned char **map;

public:

LevelMap();
~LevelMap();
};

LevelMap.cpp:

Code: [Select]

#include "LevelMap.h"

LevelMap::LevelMap(){
//Create 2d array with dimensions [30][36]
w=36; h=30;
map = new unsigned char*[h];
 
for (int wi = 0; wi < w; ++wi){
//Create array and fill every one with 0's
map[wi] = new unsigned char[h];
for (int hi = 0; hi < h; ++hi)
map[wi][hi] = 0;
}
}

LevelMap::~LevelMap(){
for (int i = 0; i < w; ++i)
delete[] map[i];
 
delete[] map; //<- creates the error

}

I tried finding my error before - I wouldn't have asked here otherwise ^^
Removing the delete[] map rids me of the error, but that'd leak the memory if I'm not mistaken.

Oh - also error now happens in debug mode too. God knows why.

[Nexus]

Code: [Select]

map = new unsigned char*[h];
     
   for (int wi = 0; wi < w; ++wi){
I think you should iterate until h, not w.

By the way, avoid manual memory management. You should use std::vector or boost::multi_array for dynamic arrays. This makes your code much more robust and less error-prone. In your example, a debug assertion would have told you about the invalid index access.

[s3rius]

Unfortunate coincidence - you're right about that, but the error snuck in when I was making the minimal code. It's not in my full code

But that brought me onto the track of the loading routine, which is the culprit.

Yes, I should probably use vectors for that. At first I didn't because I thought it would be hindering when I save/load the array into/from a binary file. The class deserves some updates, I guess.

[Nexus]

At first I didn't because I thought it would be hindering when I save/load the array into/from a binary file.

The internal representation of std::vector is guaranteed to be linear – that is, all elements lay consecutively in the memory, beginning at &myVector[0]. Hence this shouldn't be an issue.