Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 287
  • Last Modified:

No corruption running in IDE

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 ?
2 Solutions
>>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")
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.
alcindorAuthor Commented:
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.
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

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.
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.

alcindorAuthor Commented:
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

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now