Want to win a PS4? Go Premium and enter to win our High-Tech Treats giveaway. Enter to Win


No corruption running in IDE

Posted on 2014-01-27
Medium Priority
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
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
LVL 86

Accepted Solution

jkr earned 750 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 http://support.microsoft.com/kb/103861 ("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.
Independent Software Vendors: We Want Your Opinion

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

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 35

Assisted Solution

sarabande earned 750 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

Tech or Treat! - Giveaway

Submit an article about your scariest tech experience—and the solution—and you’ll be automatically entered to win one of 4 fantastic tech gadgets.

Question has a verified solution.

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

When writing generic code, using template meta-programming techniques, it is sometimes useful to know if a type is convertible to another type. A good example of when this might be is if you are writing diagnostic instrumentation for code to generat…
Programmer's Notepad is, one of the best free text editing tools available, simply because the developers appear to have second-guessed every weird problem or issue a programmer is likely to run into. One of these problems is selecting and deleti…
The goal of the tutorial is to teach the user how to use functions in C++. The video will cover how to define functions, how to call functions and how to create functions prototypes. Microsoft Visual C++ 2010 Express will be used as a text editor an…
The viewer will be introduced to the technique of using vectors in C++. The video will cover how to define a vector, store values in the vector and retrieve data from the values stored in the vector.

604 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