0

I have a Windows application, it crashes every now and then and not reroducibly. When it does, I get pure virtual function called. I have set it up to create a Windows dump using ADplus and even when it crashes, there is never a dump.

I am pretty sure this is build error, I am building using VC2008 SP1 and this is the release build.

Any insights on this? How can I debug this, it is a release build with .pdb file and map file.

Thanks Reza

reza
  • 5,972
  • 15
  • 84
  • 126

7 Answers7

2

First of all, make sure that you are not calling pure virtual function. If this is not the case, try to start your program under WinDbg.

Community
  • 1
  • 1
Kirill V. Lyadvinsky
  • 97,037
  • 24
  • 136
  • 212
2

As was pointed out already, it is very unlikely that this is a build error. I had a quite complex project with a similar problem and was able to track it down by using _set_purecall_handler and providing my own handler. This way I was able to break into the debugger when it happened and see the call stack. Obviously an alternative here is to create the minidump when it happens. Remember that you need to prepare everything for the minidump before the program encounters an exception.

However, there is also a good chance this could be caused by a heap corruption. In such a case I would expect a variety of symptoms, though. You describe this specific symptom, so it's likely that your code is indeed at fault.

The project I mentioned above was a legacy project that modeled something similar to COM and there were indeed places where the compiler could not have possibly found all occasions of pure virtual functions for which no implementation existed in derived classes.

0xC0000022L
  • 20,597
  • 9
  • 86
  • 152
  • when you say prepare everything for a minidump, what is there to do? – reza Apr 18 '11 at 17:26
  • @reza: make sure the `dbghelp.dll` is loaded and all function pointers have been retrieved (btw, not loading it is the most frequent reason why no dump file gets created - often because no recent version of the DLL exists on the system). Also, prepare a name for it. Any and all operations that you attempt when the application is "dangling" (i.e. instable) could be potentially fatal. Therefore try to do all relevant stuff before your exception handler or pure virtual function handler gets called and is supposed to create the dump file. – 0xC0000022L Apr 18 '11 at 17:38
1

I am pretty sure this is build error

Very, very unlikely. It's much more likely that this is a bug in your code.

You might be slicing an object somewhere. If you have your app set up to generate a dumpfile on unhanded exceptions and you are still dying with no dump file, then its very possible the bug is in the exception handler.

You need to get a dump file. That should be your first priority.

Community
  • 1
  • 1
John Dibling
  • 99,718
  • 31
  • 186
  • 324
0

I have the same error. I reviewed code many times and never found virtual functions usage in constructors or destructors. The problem was in build system. I had old static library version on my computer where some function wasn't pure virtual, and new one when it became (I added one more abstraction layer). Because EXE file was created with old static library, but new headers, this error appeared. So, make sure that your libraries and include files versions are consistent if nothing else helps.

Vitalii
  • 4,434
  • 4
  • 35
  • 77
0

If your issue is not constant most probably there are some problems with out of index writes which could corrupt memory

Elalfer
  • 5,312
  • 20
  • 25
0

If you've tried a full rebuild, then it seems more likely it's a coding issue.

Are you calling any (pure) virtual functions in any constructors or destructors?

More likely is that you're calling a pure virtual function on a deleted object, and the vtable has been moved to point to the parent object. In this case valgrind (free, linux) or Purify ($$$, Windows) will really be able to help you out. VS may have a memory checker with it too.

Mark B
  • 95,107
  • 10
  • 109
  • 188
0

I once had a similar problem with C++. I had a call to a virtual function from a constructor somewhere, so the object was not constructed yet when the call happened, explaining the "pure" virtual function called. It might also be a problem of slicing if you have bad casts on objects instead of pointer to objects. Use a debugger and step by step/backtrace to find the source so we can help you better.

Giovanni Funchal
  • 8,934
  • 13
  • 61
  • 110