Re: Errors: R6025 and Friends
- From: RobKinney1 <mydigitalportal.net@xxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 20 Aug 2007 10:34:03 -0700
Hello Joseph,
Thank you for your time and knowledge in responding to this post. I am glad
you responded as I forgot to post a follow up on the situation.
As it stands now, I have figured out how to shut down the program without
errors. We have a Multi-document project that is heavily using a 3rd party
set of libraries. The child windows each contained an instance of this
library (using CoCreateInstance()). The object that we were creating never
had a ->Release() executed when the user clicked the X or closed the app some
other way.
Whats funny is that we realized that it was a difference in hardware and the
drivers that would cause the problem to occur. When we installed a PCI
expansion card for our hardware (using that interface instead of the USB),
the drivers that were managing the card that interacted with the other 3rd
party libraries became extremely finicky on how everything was initialized
and uninitialized.
Now the int 3 instruction is still baffling me because it is still there
(guess it was an unconnected problem). It happens on the lines of code that
look like this:
BSTR name;
device->get_Name(&name); // int 3 thrown here
-- where device is a type of the 3rd party library. This is how their
sample code is written and their demo app throws this error as well when
trying to run in the debugger. Should I contact them and let them know about
it? You say that there may be memory damage and I hate for us to release our
software and have odd crashes start to happen...
Thanks for the info on _heapwalk()... wasn't sure if it was like .NET where
you could put the value in the watch values and have it evaluate or not (at
least that is how I remember it working... haven't programmed in it for over
6 months now).
I will look at the App Verifier as you suggest to make sure that things are
better and perhaps it will hint at what could be wrong with the
device->get_Name(&name) line.
Thank you again for your time to answer these questions. They are very
valuable to me and I read them multiple times to make sure I understand them.
Rob
---
"Joseph M. Newcomer" wrote:
See below....
On Mon, 13 Aug 2007 16:32:03 -0700, RobKinney1
<mydigitalportal.net@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Hello All!****
We have a problem... which actually may be 2 problems with one of our large
C++ 6.0 projects.
Problem #1:
On one of our test servers, we are getting an error whenever we EXIT our
program that looks like the following:
-----------------------------
Runtime Error!
Program: [path and name]
R6025
-Pure virtual function call
THis is fairly hard to accomplish, but what it means is that you called a pure method of a
class which didn't implement the virtual method, which is hard to do; you can't normally
create an instance of a class that has pure virtual methods. It is more likely you have a
bogus pointer which is giving the illusion that it is referencing a object it thinks is a
class instance. I could give a long, complex explanation of how this works by discussing
the implementation of vtables and how virtual method calls work by indexing into them, but
the other errors you are seeing suggest that you are suffering memory damage, perhaps a
dangling pointer.
****
****
[OK button]
---------------------------
I have found the following article:
http://support.microsoft.com/kb/125749
So I decided that I will run this program in Debug mode on the test server
and set a breakpoint in the ATLIMP.CPP _purecall() function (I have no idea
if I am trying to do the right thing here or not... nor will I know how to
examine the stack as they suggest to see what called it).
Problem #2 arises when I try to run this program in Debug mode with the
breakpoint set for the _purecall function on the test server. You can start
debugging and step through line-by-line for a while but SOMEWHERE (which I
cannot find either) the debugger flips to a Disassembly Screen and says -
User breakpoint called from code at 0x7c901230... with an arrow pointing to
an assembly line that says: int 3.
THis is expected behavior when you hit an int 3 instruction, which is a debugger call. If
this is called in _heapwalk() it means that you are probably damaging the heap, and you
need to fix that. Did you look at the call stack? What's in it? This is why I think you
have memory damage.
****
****
Somewhere I read that when problem #2 arises to find out what the
_heapwalk() value is by pasting that into the watch1 vars.... but that
doesn't work (says symbol _heapwalk not found)!!
pasting "that"? Do you mean the value _heapwalk? Well, that wouldn't do any good because
_heapwalk() is a function, not a variable, and it wouldn't make sense to put it in a watch
window.
*****
****
I don't understand... my personal test environment where I develop with a
different test server and client programs and computers NEVER have these
weird errors... its only when I take them to a different test environment....
We even reformatted this troublesome test server's hard drive and reinstalled
the OS and we still cannot get our program to run correctly when exiting or
debugging.
I would suggest that even thinking that reformatting a hard drive could fix a program bug
is indicative of some really warped thinking. I would not have considered such a thing as
remotely making sense.
There's bugs in your code. It's that simple. Reformatting the hard drive and
reinstalling the OS could not possibly fix bugs in your program. It certainly couldn't
fix bugs caused by what is a fairly obvious set of programming errors; all you have to
determine now is what is causing these errors (by "obvious" I mean that the diagnostics
you are getting clearly and unequivocally say 'this program has bugs'; this is so far from
saying "your hard disk is corrupted and your operating system is compromised" that the
very FIRST thing you do is figure out what's wrong with your program. Don't waste time
reformatting disks!)
What is more likely is that your "testing and development" environment isn't *really*
testing your app. When you deploy it, it executes code that you have not actually
executed in the testing process, and this hits the bug. Alternatively, the data access
patterns in your testing environment do not create the damaging situation which is due to
a program bug; but when you run in a live environment, the data access patterns cause the
program bug to manifest itself. But there is very little question that your code has at
least one serious bug. I suspect a dangling pointer.
Take a look at the App Verifier, a free download from Microsoft. It often helps in
finding these kinds of errors. Turn on all its memory detection options.
joe
****
Joseph M. Newcomer [MVP]
Any tips would greatly be appreciated!
Thanks,
Rob
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
- Follow-Ups:
- Re: Errors: R6025 and Friends
- From: Joseph M . Newcomer
- Re: Errors: R6025 and Friends
- References:
- Re: Errors: R6025 and Friends
- From: Joseph M . Newcomer
- Re: Errors: R6025 and Friends
- Prev by Date: Re: Prob opening other serial port besides COM1
- Next by Date: Re: Converting a LPSTR* to BSTR* and back again.
- Previous by thread: Re: Errors: R6025 and Friends
- Next by thread: Re: Errors: R6025 and Friends
- Index(es):
Relevant Pages
|