Error message R6025: pure virtual function call

Hello,

I had a very strange error message after running a trigger-based program at a user's site - does anyone have any idea what this message really tells? The dialog box content was:

"Runtime error!
Program: c:\program files\doors 9.3\bin\doors.exe
R6025 - pure virtual function call"

Thanks a lot in advance!

Best regards,
Gerhard
GerhardS - Wed Mar 16 03:54:20 EDT 2011

Re: Error message R6025: pure virtual function call
Mathias Mamsch - Wed Mar 16 06:01:28 EDT 2011

The "R6025 - pure virtual function call" message is an error message from the Visual C++ runtime, and means that the DOORS client has been calling a function, it is not supposed to call. So you can say, it is a DOORS bug. I think I got this error in cases when I experimented with weird things with triggers, like DXL Layout Columns installing Triggers, etc. In any case it means your DXL tried to do something it is not supposed to do,so it is likely due to a coding bug in the DXL.

Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

Re: Error message R6025: pure virtual function call
GerhardS - Wed Mar 16 07:50:49 EDT 2011

Mathias Mamsch - Wed Mar 16 06:01:28 EDT 2011
The "R6025 - pure virtual function call" message is an error message from the Visual C++ runtime, and means that the DOORS client has been calling a function, it is not supposed to call. So you can say, it is a DOORS bug. I think I got this error in cases when I experimented with weird things with triggers, like DXL Layout Columns installing Triggers, etc. In any case it means your DXL tried to do something it is not supposed to do,so it is likely due to a coding bug in the DXL.

Regards, Mathias

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

Thanks a lot, Matthias.

Re: Error message R6025: pure virtual function call
SystemAdmin - Fri Aug 19 06:45:43 EDT 2011

Mathias Mamsch - Wed Mar 16 06:01:28 EDT 2011
The "R6025 - pure virtual function call" message is an error message from the Visual C++ runtime, and means that the DOORS client has been calling a function, it is not supposed to call. So you can say, it is a DOORS bug. I think I got this error in cases when I experimented with weird things with triggers, like DXL Layout Columns installing Triggers, etc. In any case it means your DXL tried to do something it is not supposed to do,so it is likely due to a coding bug in the DXL.

Regards, Mathias

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

Apart from triggers when this error can come, because I also faced this issue but I have never used triggers and it came just for few time and then it never came again. so can you please explain me.

I am using Doors 9.2, Windows 7

Thanks,
Hardik Shah

Re: Error message R6025: pure virtual function call
Mathias Mamsch - Fri Aug 19 07:34:20 EDT 2011

SystemAdmin - Fri Aug 19 06:45:43 EDT 2011
Apart from triggers when this error can come, because I also faced this issue but I have never used triggers and it came just for few time and then it never came again. so can you please explain me.

I am using Doors 9.2, Windows 7

Thanks,
Hardik Shah

Well what DID you do, just before the error message appeared? Regards, Mathias

Re: Error message R6025: pure virtual function call
SystemAdmin - Fri Aug 19 08:47:31 EDT 2011

Mathias Mamsch - Fri Aug 19 07:34:20 EDT 2011
Well what DID you do, just before the error message appeared? Regards, Mathias

well sorry its difficult to find what operation I had did as from API the operation is performed also (I am using doors as a batch server...)
It can be get,create,update, iterating history,set filter any one of this, but all this operation I am doing now also but that issue is not came now. infect this issue is faced only once from last one year.

Thanks,
Hardik Shah

Re: Error message R6025: pure virtual function call
SystemAdmin - Wed Sep 07 06:13:31 EDT 2011

SystemAdmin - Fri Aug 19 08:47:31 EDT 2011
well sorry its difficult to find what operation I had did as from API the operation is performed also (I am using doors as a batch server...)
It can be get,create,update, iterating history,set filter any one of this, but all this operation I am doing now also but that issue is not came now. infect this issue is faced only once from last one year.

Thanks,
Hardik Shah

I had reproduced this error.

if we access deleted object's absolute number then this error occurs and then Doors will be closed.
  

Module moduleVar = edit("/Project1/Module1",false)
Object objectVar = object(330, moduleVar)
delete objectVar
flushDeletions()
Project projectVar= getParentProject(moduleVar)
string resultVar = "\"" uniqueID(projectVar) "_" uniqueID(moduleVar) "_" objectVar."Absolute Number" "\""

 


Thanks,
Hardik Shah

 

Re: Error message R6025: pure virtual function call
llandale - Wed Sep 07 13:26:40 EDT 2011

SystemAdmin - Wed Sep 07 06:13:31 EDT 2011

I had reproduced this error.

if we access deleted object's absolute number then this error occurs and then Doors will be closed.
  

Module moduleVar = edit("/Project1/Module1",false)
Object objectVar = object(330, moduleVar)
delete objectVar
flushDeletions()
Project projectVar= getParentProject(moduleVar)
string resultVar = "\"" uniqueID(projectVar) "_" uniqueID(moduleVar) "_" objectVar."Absolute Number" "\""

 


Thanks,
Hardik Shah

 

delete(Object) is the same as hardDelete(Object), and once you flushDeletions that object is gone and you cannot use its Handle which you do in the last resultVar statement. OK, "cannot" is a hard word since it seems to me that it takes about a short period of time from the "flush" command before the Handle becomes corrupt, so sometimes accessing the Handle works, but its bad Karma to do so. Get the AbsNo before deleting and display that, unless you just want to go ahead and hard code "330" again.

I would also like to point out that the "object(AbsNo, Module)" command only finds objects that are currently displayed and may not find your object. Also, "delete(Object)" only works on currently UNDELETED objects, so if the object is deleted you must first undelete it.

  • Louie

OK, "Gone" is a bit hard to because if you fail to save the module it will be there next time.

Re: Error message R6025: pure virtual function call
emily_butt - Tue Feb 14 08:38:16 EST 2012

I have begun to get this error as well, but in a different scenario.
I'm working some DXL with a dialog box that displays the text of the current object (with the ability to navigate between objects using the dialog box) and also displays the text of the objects that the current object links to (with the ability to navigate through the links for each object). I also want to add the ability to open the target module to the targeted object from the dialog box. It works, BUT if I close the target module and try to continue using the dialog box I get the "pure virtual function call" error every time.

Here is the code I have for the dialog box button that opens the target:
  

void goToTarget ( DBE TargetGoToButton ) {
    Object o
        Module m, mm
        string targetModName, cmtModName
        int abstgt,abscurr
        o = getTargetObject()
        if ( o == null ){
                ack "no target object"
        } else {
                m = module ( o )
                targetModName = fullName ( m )
                cmtModName = fullName ( CmtMod )
                if ( targetModName == null )
                        ack "error with path to target module"
                else {
                        mm = read ( targetModName, true, true )
                        abstgt = o."Absolute Number"
                        abscurr = CurObj."Absolute Number"
                        gotoObject ( abstgt, mm )
                        gotoObject ( abscurr, CmtMod )
                }
        }
}

 


I suspect using gotoObject is to blame, but I'm not sure. Is there a better way to open the target module to the target object than this?

Thanks!

 

Re: Error message R6025: pure virtual function call
llandale - Tue Feb 14 10:47:34 EST 2012

emily_butt - Tue Feb 14 08:38:16 EST 2012

I have begun to get this error as well, but in a different scenario.
I'm working some DXL with a dialog box that displays the text of the current object (with the ability to navigate between objects using the dialog box) and also displays the text of the objects that the current object links to (with the ability to navigate through the links for each object). I also want to add the ability to open the target module to the targeted object from the dialog box. It works, BUT if I close the target module and try to continue using the dialog box I get the "pure virtual function call" error every time.

Here is the code I have for the dialog box button that opens the target:
  

void goToTarget ( DBE TargetGoToButton ) {
    Object o
        Module m, mm
        string targetModName, cmtModName
        int abstgt,abscurr
        o = getTargetObject()
        if ( o == null ){
                ack "no target object"
        } else {
                m = module ( o )
                targetModName = fullName ( m )
                cmtModName = fullName ( CmtMod )
                if ( targetModName == null )
                        ack "error with path to target module"
                else {
                        mm = read ( targetModName, true, true )
                        abstgt = o."Absolute Number"
                        abscurr = CurObj."Absolute Number"
                        gotoObject ( abstgt, mm )
                        gotoObject ( abscurr, CmtMod )
                }
        }
}

 


I suspect using gotoObject is to blame, but I'm not sure. Is there a better way to open the target module to the target object than this?

Thanks!

 

This does not look right.
  • if "m" is null then "fullName(m)" will generate a DXL error.
  • if "m" is not null, then you don't need to read the module and assign "mm".

Perhaps you pre-store all the "Object" handles of the link targets and displays on the dialog, and when they select one "getTargetObject" retrieves that handle. If you are saying you have a problem if you display the links, close the target module, and then the user selects one and "getTargetObject" returns an "Object" handle, yes that handle is non-null but also is corrupted, and surely there are will be errors down the road.

If so, I would:
[A] "block" the dialog strongly discouraging casual closing of the module
[B] in this function, check of that module is still open, and if not open it and re-display the dialog. This is tricky since you have corruption if you display, and the user then closes and re-opens the module; in which case it "is" open but the handles are still corrupted.
[C] Somehow remember the AbsNo of the target objects so when they select one and the module is closed, you open the module and re-acquire the Object handle in question; or better yet just "gotoObject(AbsNo, NewModuleHandle)"

I think I like [C]. write function "int getTargetObject()"; remember the fullName of the target module, then:
  • mm = read(NameTargetFull, true, true)
  • gotoObject(AbsNoTarget, mm)

-Louie

Re: Error message R6025: pure virtual function call
Thosicus - Wed Mar 07 14:02:20 EST 2012

llandale - Tue Feb 14 10:47:34 EST 2012
This does not look right.

  • if "m" is null then "fullName(m)" will generate a DXL error.
  • if "m" is not null, then you don't need to read the module and assign "mm".

Perhaps you pre-store all the "Object" handles of the link targets and displays on the dialog, and when they select one "getTargetObject" retrieves that handle. If you are saying you have a problem if you display the links, close the target module, and then the user selects one and "getTargetObject" returns an "Object" handle, yes that handle is non-null but also is corrupted, and surely there are will be errors down the road.

If so, I would:
[A] "block" the dialog strongly discouraging casual closing of the module
[B] in this function, check of that module is still open, and if not open it and re-display the dialog. This is tricky since you have corruption if you display, and the user then closes and re-opens the module; in which case it "is" open but the handles are still corrupted.
[C] Somehow remember the AbsNo of the target objects so when they select one and the module is closed, you open the module and re-acquire the Object handle in question; or better yet just "gotoObject(AbsNo, NewModuleHandle)"

I think I like [C]. write function "int getTargetObject()"; remember the fullName of the target module, then:
  • mm = read(NameTargetFull, true, true)
  • gotoObject(AbsNoTarget, mm)

-Louie

I'm not 100% sure, but i suspect another cause of this weird error is when you do this:
Cache objects in a skip list, then try to extract their attribute values from that skip list AFTER closing the source module (where the objects came from). When I moved the 'close module' line below the code that extracts attribute values from the skip list, the error went away.

Re: Error message R6025: pure virtual function call
llandale - Wed Mar 07 17:26:18 EST 2012

Thosicus - Wed Mar 07 14:02:20 EST 2012
I'm not 100% sure, but i suspect another cause of this weird error is when you do this:
Cache objects in a skip list, then try to extract their attribute values from that skip list AFTER closing the source module (where the objects came from). When I moved the 'close module' line below the code that extracts attribute values from the skip list, the error went away.

Yes, when you close the Module its Object handles are corrupted. But not erased. Ditto for the Module handle. So when you close a module your code logic needs to be sure it doesn't use such data structures again.

-Louie

Re: Error message R6025: pure virtual function call
chrisroy - Mon Jul 31 12:10:33 EDT 2017

When I got this error message, I had a script that used the "print" statement and tried to close(module) the module.  It was a multi-baseline/module script and I guess the print statement opened the dialog in that module and disallowed the use of closing the module.  I was using the "print" statements to find bugs.  When I got rid of the print statements the module was able to close just fine.