I recently moved from VS .NET 2003 to VC++ 2005 Express. I imported my latest project (a program replete with std::string). Everything compiles just fine, but now the program crashes when it hits the std::string destructor. My output spew says this: First-chance exception at 0x7c81eb33 in GUIBuilder.exe: Microsoft C++ exception: GUIException at memory location 0x0012f7f0.. The thread 'Win32 Thread' (0xf48) has exited with code 0 (0x0). HEAP[GUIBuilder.exe]: Invalid Address specified to RtlValidateHeap( 01510000, 01525F68 ) Windows has triggered a breakpoint in GUIBuilder.exe. This may be due to a corruption of the heap, and indicates a bug in GUIBuilder.exe or any of the DLLs it has loaded. The output window may have more diagnostic information My project consists of an EXE with four supporting DLLs. The DLLs contain the heart of my GUI drawing code, and the EXE is an editor to allow the creation of GUIs using my system. The program is crashing when it returns from the function with the following prototype: void RunScript(const string& filename); This function takes the name of a script file and passses it to the scripting engine inside the GUI system. When the destructor is called on the parameter, the program goes belly-up. I've also tried commenting this line out, and the program crashes as soon as the destructor on a string is called. I remember having a similar problem awhile back, and the problem was related to the EXE trying to manipulate the DLL's heap, or vice versa. I seem to remember the problem being related to the run-time libraries that the projects were using, but I can't remember the details. Thus far my fiddling with the project settings has been futile. Please help, as this project represents a significant code base and it would be a real pain to have to go through and weed out all the std::strings that I've used throughout the project.

A reference going out of scope shouldn't call a destructor. It is like passing a pointer.

I haven't made any DLLs, but I've heard that you can have problems if memory is newed in one DLL/inside the main app and freed in another DLL/ inside the main app.

Quote:Original post by rip-off
A reference going out of scope shouldn't call a destructor. It is like passing a pointer.

Since I am passing in the string like this:

RunScript("Startup.lua")

Probably what is happening is it is creating a string on the fly and the destructor is being called on that. For the record, I tried changing the function to pass-by-value and it didn't make a difference.

Quote:Original post by rip-off
I haven't made any DLLs, but I've heard that you can have problems if memory is newed in one DLL/inside the main app and freed in another DLL/ inside the main app.

Yes, I think that is the problem that I'm experiencing, although I can't really see how I'm doing that in my code.

Clutching at straws here, so this probably won't help.

Keep the original pass-by-reference, and call like so:

std::string script = "Startup.lua";
RunScript( script );

If the problem is in the destructor still, try a char * and .c_str()

Failing that, listen to someone who knows what they're on about...[smile]

Not a bad thought, and interestingly enough...

Now the problem comes when it calls the destructor on the temporary string that I've created (the "script" variable from your example). Very strange indeed...

Quote:Original post by bpoint
A memory overwrite bug somewhere, perhaps?

You could try adding:

	HeapValidate(GetProcessHeap(), 0, NULL);

in various parts of your code, especially around the call to RunScript.

Also, have you recompiled all of the DLLs under VC2005?

Just a guess, though... I personally stay very far away from STL, so I probably won't be of much more help. :(

I don't think so, simply because everything worked perfectly fine under VS .NET 2003. And yes, I have recompiled everything under VC++ 2005.

I would just go back to VS .NET 2003 if only I could find my prereqs CD...

if I were you, I'd change the function to a const char * parameter, and forget std::string completely - see if that solves your problem. With DLLs, yes it's an issue of ( if this is really the problem ) of different runtime libraries ( that the dll was compiled with, for example with your older compiler ) having different implementations of the stl, and thus different memory management implementations; hence your bug. Following this, you could simply recompile your dll with your new compiler, that should fix the bug if you link it to the same runtime library that your app is running. But, again, go to a const char * parameter, and see if that fixes things first of all.

*edit* d'oh, but if you change to const char *, then you must recompile anyway...
*edit2* also, if you don't want to recompile, then you could just allocate the string as new string str;, and not bother deleting ( again for testing purposes ), and pass *str as the parameter. No delete == no destructor.

[Edited by - squirrel_of_death on May 2, 2006 8:27:50 PM]

Quote:Original post by squirrel_of_death
if I were you, I'd change the function to a const char * parameter, and forget std::string completely - see if that solves your problem. With DLLs, yes it's an issue of ( if this is really the problem ) of different runtime libraries ( that the dll was compiled with, for example with your older compiler ) having different implementations of the stl, and thus different memory management implementations; hence your bug. Following this, you could simply recompile your dll with your new compiler, that should fix the bug if you link it to the same runtime library that your app is running. But, again, go to a const char * parameter, and see if that fixes things first of all.

*edit* d'oh, but if you change to const char *, then you must recompile anyway...
*edit2* also, if you don't want to recompile, then you could just allocate the string as new string str;, and not bother deleting ( again for testing purposes ), and pass *str as the parameter. No delete == no destructor.

I've already tried recompiling the DLLs with the new compiler... No luck.

As for changing to char*, that would certainly fix the problem, but would take hours upon hours to implement, given that this is but one of MANY functions that use std::string. I would have to pour over thousands of lines of code, converting assignment operators to strcpy() and so on. A real headache.

How would changing the function to accept a char* take hours? That should be trivial since the string class has the .c_str() method.