No corruption running in IDE

Posted on 2014-01-27
Last Modified: 2014-02-01
I have a large Windows Xp application built with Borland C++ builder 5.
Recently the application exhibits errors due to an Access violation exception which appears to be due to memory corruption.
The problem does not occur when the application is run in the Borland C++ builder IDE. I have set break points to trap the error in the debugger but the program runs without error when under he IDE.
 Any suggestions as to how this issue can be tracked down ?
I have placed try .. catch blocks at various places and exceptions are caught so I can see what variables are getting corrupted (when not running in the IDE) but cannot see any further detail because the issue does not occur when running in the IDE.
 I have attached to the process with the IDE and can see the corrupt variable but can't see what is causing the corruption.
 What difference can running a program I the IDE make ?
Question by:alcindor
LVL 86

Accepted Solution

jkr earned 250 total points
ID: 39813497
>>What difference can running a program I the IDE make ?

When running under a debugger, memory and variables are initialized differently. Which in turn points to an uninitialized variable being the pointer. If you set up XP to transfer control to the debugger you'll be able to narrow doen where that happens in your code and can investigate further. See ("INFO: Choosing the Debugger That the System Will Spawn")
LVL 16

Expert Comment

ID: 39815063
In reading over your description, variable initialization hit me as well as a possible source of your problems.

While I'm not experienced with recent Borland compilers, I know that in Visual Studio, in DEBUG mode, all variables get initialized with special values so that the debugger can tell if you are reading from uninitialized memory.  Therefore the reason things are different at run time is that memory is setup differently.

The other thing I seem to recall in Visual Studio is that it takes a compiler option to make memory access errors throw errors that can be caught with try/catch.

Author Comment

ID: 39815428
I am able to catch the exceptions using try and catch but this is just seeing the side effects of the root cause.
I really need to run in the IDE and set up a "break on change" breakpoint for the variable in question so that I can view the call stack at that point to see what is changing the variable.
The debugger is set to invoke the IDE but as just mentioned, this is just showing the variable that has been corrupted and not what has corrupted it.
The program is complex and has upwards of 40 compilation units and in theory, any corrupt or un-initialised variable could conceivably be responsible for the corruption.
I have checked all the initialisations of the unit where the corrupted variable is declared and there are no initialisation errors there.
I agree that the cause is likely to be an un-initialised variable.
Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

LVL 86

Expert Comment

ID: 39815470
Are you able to obtain e.g. a Dr. Watson dump after that crash occurs? That alone might help to narrow down the cause for this. BTW, if your compiler/linker offers that (and it should), a map file would be useful as well.
LVL 33

Assisted Solution

sarabande earned 250 total points
ID: 39815682
to add to above suggestions:

access violation is pointer error. a pointer is null, or not valid. that might be due to memory corruption. memory corruption often happens because of writing beyond array boundaries or by returning pointers of locally defined objects or uninitialized pointers.

if you check your code that all pointers were properly initialized, all array indices were valid, and no local pointers were returned, it is a good chance that you could spot the culprit.  

generally, in c++ you mostly can avoid to use pointers in the interface but passing your objects by reference instead. or make them members of a class and handle allocation/deallocation in the constructor/destructor.

if nothing helps, you may find out the statement where the crash happens by using message boxes (or log messages to file if it is a console program or service; close and reopen the logfile for each log message) at begin and end of functions. first begin with a top function like main or your main dialog function or the handler of a message which likely is the caller of the crashing function. if both begin and end message were shown, you need to choose another function. if only the begin message arises but not the end you may move both messages together until only one statement is between them. then you can repeat that with the function that was called  in the remaining statement (if it is more than one function you should separate the calls such that the remaining statement has only one call). if you proceed with that you finally should have only one call to a function where you don't have a source, or where the statement itself contains the bug. print the pointers to a log file or to a stringstream such that you could add them to the messages. in any case you should have a chance now to find the bug.

alternatively to that, you could add a try - catch block to all of your functions where the catch(...) would output a message with the name of the function. you could use macros for easier adding the exception handling.


Author Closing Comment

ID: 39826216
This is going to take some time to track down.
My next approach will be to run the application with Codeguard to try and track down any array bounds violations etc. As I said, I know where the crash happens and it is due to a pointer having been corrupted. The place where the pointer is being corrupted is what I need to find.
Meanwhile, I have declared another pointer elsewhere and initialised that to the same value as the original pointer, I then replaced references to the original pointer with references to the newly declared pointer and this has provided a temporary fix until I can locate where the original pointer is being corrupted.

Thanks for your comments,


Featured Post

Is Your Active Directory as Secure as You Think?

More than 75% of all records are compromised because of the loss or theft of a privileged credential. Experts have been exploring Active Directory infrastructure to identify key threats and establish best practices for keeping data safe. Attend this month’s webinar to learn more.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Article by: SunnyDark
This article's goal is to present you with an easy to use XML wrapper for C++ and also present some interesting techniques that you might use with MS C++. The reason I built this class is to ease the pain of using XML files with C++, since there is…
Go is an acronym of golang, is a programming language developed Google in 2007. Go is a new language that is mostly in the C family, with significant input from Pascal/Modula/Oberon family. Hence Go arisen as low-level language with fast compilation…
THe viewer will learn how to use NetBeans IDE 8.0 for Windows to perform CRUD operations on a MySql database.
The goal of the video will be to teach the user the concept of local variables and scope. An example of a locally defined variable will be given as well as an explanation of what scope is in C++. The local variable and concept of scope will be relat…

920 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

14 Experts available now in Live!

Get 1:1 Help Now