Raveler
asked on
program crashes in no-debug mode
Hello,
I have an incredibly weird problem with a small console application I've been writing. It's basically a console application to create/extract an archive type I've created myself.
What happens is that everything works fine as long as single-threaded DEBUG is turned on at my Visual Studio .NET compiler options. When I set it to single-threaded (default in release configuration), the program crashes at seamingly random lines (it crashes just after a cout << "test" << boolvarhere; line, and if I remove that line it just crashes at the beginning of the next while loop) with an error about heap allocation.
To be precise, the error I get is:
Unhandled exception at 0x77f485c0 in KARTool.exe: 0xC0000005: Access violation writing location 0x454e2e20.
The debugger points at line "return HeapAlloc(_crtheap, 0, size);" in malloc.c.
Also, the program only seems to crash if I enter a string of exactly 7 characters in one of the cin calls a few lines earlier. If I enter a 8-char string or a 6-char string the program continues but I'm sure it will crash eventually. Right now I've commented about 80% of the whole program and it still crashes after a few lines.
I don't use threads or anything and I haven't included any platform-specific headers. I only used the C++ standard library and a few functions from stdio.h/string.h.
As said earlier: I can fix the problem by turning single-threaded debug on, but that substantially increases the size of my executable and I want to get rid of this problem once and for all, not run from it. I had the same thing with one of my previous projects as well and I couldn't fix it back then either.
Thanks!
Karel Crombecq
I have an incredibly weird problem with a small console application I've been writing. It's basically a console application to create/extract an archive type I've created myself.
What happens is that everything works fine as long as single-threaded DEBUG is turned on at my Visual Studio .NET compiler options. When I set it to single-threaded (default in release configuration), the program crashes at seamingly random lines (it crashes just after a cout << "test" << boolvarhere; line, and if I remove that line it just crashes at the beginning of the next while loop) with an error about heap allocation.
To be precise, the error I get is:
Unhandled exception at 0x77f485c0 in KARTool.exe: 0xC0000005: Access violation writing location 0x454e2e20.
The debugger points at line "return HeapAlloc(_crtheap, 0, size);" in malloc.c.
Also, the program only seems to crash if I enter a string of exactly 7 characters in one of the cin calls a few lines earlier. If I enter a 8-char string or a 6-char string the program continues but I'm sure it will crash eventually. Right now I've commented about 80% of the whole program and it still crashes after a few lines.
I don't use threads or anything and I haven't included any platform-specific headers. I only used the C++ standard library and a few functions from stdio.h/string.h.
As said earlier: I can fix the problem by turning single-threaded debug on, but that substantially increases the size of my executable and I want to get rid of this problem once and for all, not run from it. I had the same thing with one of my previous projects as well and I couldn't fix it back then either.
Thanks!
Karel Crombecq
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Please show your code.
ASKER
You guys could have been right. Somewhere I found this piece of code:
fArchiveName = new char[strlen(archiveName)];
strcpy(fArchiveName, archiveName);
Guess I didn't leave any more room for the NULL terminating character. The program doesn't crash anymore but that doesn't mean anything because the crashes were very random. However I don't understand why it was crashing at the cout line then, as it doesn't have anything at all to do with the string that was copied (in fact, it wasn't used at all).
I'm gonna experiment some more and let you guys know.
fArchiveName = new char[strlen(archiveName)];
strcpy(fArchiveName, archiveName);
Guess I didn't leave any more room for the NULL terminating character. The program doesn't crash anymore but that doesn't mean anything because the crashes were very random. However I don't understand why it was crashing at the cout line then, as it doesn't have anything at all to do with the string that was copied (in fact, it wasn't used at all).
I'm gonna experiment some more and let you guys know.
ASKER
Okay, grg99's excellent debug function brought certainty. I managed to reproduce the crash. It was indeed the strcpy() function I mentioned earlier.
I guess the single threaded debug option has a few heap security checks that the non-debug version doesn't have.
I'm going to split the points evenly amongst kremer and grg (kremer for pointing me in the right direction and grg for providing a function that will surely help me a lot in the future).
I guess the single threaded debug option has a few heap security checks that the non-debug version doesn't have.
I'm going to split the points evenly amongst kremer and grg (kremer for pointing me in the right direction and grg for providing a function that will surely help me a lot in the future).
Here's a few more tips:
#define sprintf NoGoodRoutine::sprintf
#define gets NoGoodRoutine::gets
#define strcpy NoGoodRoutine::strcpy
#define strcat NoGoodRoutine::strcat
This wil help you catch all uses of these old and very dangerous functions.
All these functions should be replaced by their safer "sn" versions.
#define sprintf NoGoodRoutine::sprintf
#define gets NoGoodRoutine::gets
#define strcpy NoGoodRoutine::strcpy
#define strcat NoGoodRoutine::strcat
This wil help you catch all uses of these old and very dangerous functions.
All these functions should be replaced by their safer "sn" versions.