Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Trapping R6025 errors in the MS Visual Studio v7 debugger.

Status
Not open for further replies.

spoddynerd

Programmer
Dec 11, 2002
33
0
0
GB
I am encountering an R6025 ("No object has been instantiated to handle the pure virtual function call") error in a complex application.
The error is intermittent and it is time consuming to reproduce.
I have read that setting a breakpoint in purevirt.c at the line "_amsg_exit(_RT_PUREVIRT);" will trap the error, but when I attach to my application, the debugger does not stop.

I tried to deliberately reproduce the same error in a much simpler application so that I knew how to trap it. (The code is reproduced below, borrowed from another post on R6025).
Setting the breakpoint as specified above succeeded in this (simple) case.

I have noticed that the dialog box shown in each case is different.
In the simple case, the runtime error identifies the debug library in the menu bar and offers 'abort'/'retry'/'ignore' radio buttons (hence the facility to stop the debugger through 'retry' and catch the error on the stack).
In the complex case, the runtime error identifies the runtime library in the menu bar and only offers an 'ok' radio button.

In both cases, the issue is *NOT* related to whether or not debug symbols are included in the build.

Questions:
1. What determines the format of the dialog box reporting the R6025? is it that in the simple case, the code is such that the error can be caught earlier, i.e. by the debugging environment and is therefore possible to debug, whereas in the complex case, a subtle coding difference causes the error to be caught later, e.g. by the operating system, and is therefore not possible to debug?

2. If it is indeed the nature of the code that causes the difference, then can anyone provide code that would result in the 'more limited' runtime version of the dialog box? How could this error be trapped?

3. If on the other hand the difference is due to some environment/ build setting, then what specific setting causes the difference?

Code:
#include <iostream>

class A;

void f(A& a);

class A {
public:
A();
virtual void pure() = 0;
};

A::A()
{
f(*this);
}

class B : public A {
public:
virtual void pure();
};

void B:pure()
{
}

void f(A& a)
{
a.pure();
}

int main()
{
try {
B b;
}
catch (...) {
std::cout << "Caught exception" << std::endl;
}
return 0;
}
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top