Unhandled Exception with c++ app on Visual Studio 2008 release build - occurs when returning from function

I have a (rather large) application that I have written in C++ and until recently it has been running fine outside of visual studio from the release build. However, now, whenever I run it it says "Unhandled exception at 0x77cf205b in myprog.exe: 0xC0000005: Access violation writing location 0x45000200.", and leads me to "crtexe.c" at line 582 ("mainret = main(argc, argv, envp);") if I attempt to debug it. Note that this problem never shows if I run my debug executable outside of visual studio, or if I run my debug or release build within visual studio. It only happens when running the release build outside of visual studio.

I have been through and put plenty of printfs and a couple of while(1)s in it to see when it actually crashed, and found that the access violation occurs at exactly the point that the value is returned from the function (I'm returning a pointer to an object). I don't fully understand why I would get an access violation at the point it returns, and it doesn't seem to matter what I'm returning as it still occurs when I return 0.

The point it started crashing was when I added a function which does a lot of reading from a file using ifstream. I am opening the stream every time I attempt to read a new file and close it when I finish reading it.

If I keep attempting to run it, it will run once in about 20 tries. It seems a lot more reliable if I run it off my pen drive (it seems to crash the first 3 or 4 times then run fine after that - maybe it's due to its slower read speed).

Thanks for your help, and if I've missed anything let me know.

EDIT: New info

Well I removed the entirity of the function and replaced it with:

IndexedMesh * loadObj(char * objName)
{

ifstream fp_in;
fp_in.open("lol.bmp", ios::in);

fp_in.clear();
fp_in.close();

IndexedMesh * mesh = new IndexedMesh();

printf("finished");


return mesh;
}

I also tried it with "return 0" and "return new IndexedMesh()". It's all fine until you put the ifstream stuff in. I do have 2 other ifstreams open in different functions (accessing completely different files). Could this be the problem?

It actually errors on the return mesh li开发者_如何学Pythonne, (I got the debugger working with the separate release file). It completely nulls the mesh object when it attempts to return it.

The point it started crashing was when I added a function which does a lot of reading from a file using ifstream. I am opening the stream every time I attempt to read a new file and close it when I finish reading it.

Given your description of the code only failing in release mode outside the debugger I'd examine this function for any unset variables. Compiling debug sets variables (or at least it used to) as did running release code in the debugger.

You are probably running over something stored deep in the stack.

I'll bet that if you were to put this at near the top of your code:

int my_main(int argc, char * argv[], char * envp[]);

int main(int argc, char * argv[], char * envp) {
    char ** a;
    char ** e;
    a = malloc(argc+1); // note: you should test the results for NULL
    e = malloc(1+count(envp) ) ;// I'm not writing code to count it, but it's easy

    int i = 0;
    while (argv[i++]) {
       a[i] = strdup(argv[i]);
    }
    a[i] = argv[i]; // argv[i] is NULL and already in a register

    // do the same thing for envp

    return my_main(argc, a, e);
}
#define main my_main

then whatever it is that is smashing your stack would instead end up smashing this duplicated environment. It's not garenteed, and it is no fix for your problem, but not that difficult.

Thanks very much for your help, I haven't exactly solved the problem but I have managed to evade it. Basically, if I even mentioned an ifsteam (in that function and that function only), the program crashed.

I actually went as far as altering the function to simply declare an ifstream then return 0. I "fixed" it by declaring the ifstreams as pointers and new-ing them. If I deleted the pointer it crashed out again so I had to set it to 0 (leeeeak).

If anyone could enlighten me as to why this occurs, that would be great. While I'm just happy it works now, I'd rather know why..