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
RavelerAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Karl Heinz KremerCommented:
This is very likely a problem with corrupted memory. Without seeing the source code it's pretty hard to pinpoint the exact source of the problem. Because you write that you are using functions from string.h, it's very likely that you are overwriting memory that you don't own. Which functions of string.h are you using, and how are you using them? You need to make sure that the memory that the functions expect to be allocated is actually there. Most of these functions do not allocate memory for you, you have to provide it before you call the function (e.g. strcpy expects that your target string is large enough to hold your source string).
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
grg99Commented:
You might be able to narrow down the problem area by sprinkling a few calls to the following function
thruout your code:


void CheckHeap( char * Tag ) {
    int Len;
   fprintf( stderr, "Got to: %s\n", Tag );  
   for( Len = 10; Len < 10000; Len *= 2 ) free( malloc( Len ) );
}

It exercises the heap a bit and will bomb out if you've overrun a heap block somewhere.
It's found many a problem in my own code!


 
0
AlexFMCommented:
Please show your code.
0
Exploring SharePoint 2016

Explore SharePoint 2016, the web-based, collaborative platform that integrates with Microsoft Office to provide intranets, secure document management, and collaboration so you can develop your online and offline capabilities.

RavelerAuthor Commented:
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.
0
RavelerAuthor Commented:
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).
0
grg99Commented:
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.



0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
C++

From novice to tech pro — start learning today.