Solved

No corruption running in IDE

Posted on 2014-01-27
6
266 Views
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 ?
0
Comment
Question by:alcindor
6 Comments
 
LVL 86

Accepted Solution

by:
jkr earned 250 total points
Comment Utility
>>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")
0
 
LVL 16

Expert Comment

by:HooKooDooKu
Comment Utility
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.
0
 
LVL 2

Author Comment

by:alcindor
Comment Utility
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.
0
Threat Intelligence Starter Resources

Integrating threat intelligence can be challenging, and not all companies are ready. These resources can help you build awareness and prepare for defense.

 
LVL 86

Expert Comment

by:jkr
Comment Utility
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.
0
 
LVL 32

Assisted Solution

by:sarabande
sarabande earned 250 total points
Comment Utility
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.

Sara
0
 
LVL 2

Author Closing Comment

by:alcindor
Comment Utility
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,

Roger
0

Featured Post

What Should I Do With This Threat Intelligence?

Are you wondering if you actually need threat intelligence? The answer is yes. We explain the basics for creating useful threat intelligence.

Join & Write a Comment

Suggested Solutions

This article will show you some of the more useful Standard Template Library (STL) algorithms through the use of working examples.  You will learn about how these algorithms fit into the STL architecture, how they work with STL containers, and why t…
Basic understanding on "OO- Object Orientation" is needed for designing a logical solution to solve a problem. Basic OOAD is a prerequisite for a coder to ensure that they follow the basic design of OO. This would help developers to understand the b…
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 goal of the video will be to teach the user the difference and consequence of passing data by value vs passing data by reference in C++. An example of passing data by value as well as an example of passing data by reference will be be given. Bot…

744 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

15 Experts available now in Live!

Get 1:1 Help Now