0

I'm writing a game in C++ with a little known game framework known as Proton SDK by Seth A. Robinson. I am getting a runtime error like the one shown below..

Runtime Error!

I don't get trapped in the debugger, and the game still runs just fine while the dialog is open, but when I click OK on the dialog, the game closes.

I'm unable to provide any code as I've not been able to track down the cause of this problem simply due to the fact that the error doesn't trip up the debugger, instead just closes the program when I click OK and keeps it running while the dialog is open.

Other runtime errors show the usual abort, retry, cancel prompt, but this one just says "OK"?

I'm frustrated. I've been dealing with this issue for several months.

iProgramInCpp
  • 1
  • 2
  • 1
    Are you starting a thread from a base class constructor that directly or indirectly calls a pure `virtual` function? – Ted Lyngmo Aug 02 '22 at 20:46
  • [Example](https://godbolt.org/z/osM8n3bqT) – Ted Lyngmo Aug 02 '22 at 20:52
  • 4
    Does this answer your question? [Where do "pure virtual function call" crashes come from?](https://stackoverflow.com/questions/99552/where-do-pure-virtual-function-call-crashes-come-from) – gerum Aug 02 '22 at 20:53
  • The game logic is single threaded. The only thing I initialize is an audio worker, which is spawned like this from an Init function: `m_thread = std::move(thread(&AudioWorker::Thread, this));` – iProgramInCpp Aug 02 '22 at 20:54
  • @gerum It doesn't. I've looked through the entire source tree for function definitions that end with `) = 0;` (deleted virtual functions) and couldn't find any. Maybe there's a few that have escaped my attention but I don't recall deleting virtuals myself – iProgramInCpp Aug 02 '22 at 20:55
  • It's important to note that I still got that crash even before I added the audio worker thread thing – iProgramInCpp Aug 02 '22 at 20:57
  • _"I've looked through the entire source tree for function definitions that end with ) = 0; and couldn't find any"_ Given the error message, you can reliably assume that your codebase has pure virtual functions somewhere. – Drew Dormann Aug 02 '22 at 20:57
  • 1
    It doesn't have to be threads. I'm guessing that somewhere there is a call to a pure `virtual` function that originates from a constructor. I'd search through them all. – Ted Lyngmo Aug 02 '22 at 20:57
  • @DrewDormann I think this is pretty obvious, I wouldn't have posted this question if that weren't the case. The only problem now is tracking it down... – iProgramInCpp Aug 02 '22 at 20:58
  • The runtime error just says "runtime error". It doesn't say "where" the runtime error is. It doesn't even give me the option to trap into a debugger, as, for example, a failed assertion would. The linked image shows what I'm talking about – iProgramInCpp Aug 02 '22 at 20:59
  • Temporarily, change every pure virtual function into one whose base implementation produces some output. Then see which function's output you get. – David Schwartz Aug 02 '22 at 21:06
  • Did you include Proton SDK when you "looked through the entire source tree"? – Avi Berger Aug 02 '22 at 21:07
  • Yes. Only things I don't use in the SDK itself have pure virtual functions – iProgramInCpp Aug 02 '22 at 21:09
  • I would use the [AddressSanitizer](https://learn.microsoft.com/en-us/cpp/sanitizers/asan?view=msvc-170) - I haven't used it in VS-projects myself but use it all the time with `g++` and `clang++` and it rarely fails to pinpoint issues like this. Try compiling with `/Z7 /fsanitize=address` and then run your program. – Ted Lyngmo Aug 02 '22 at 21:58
  • I sometimes see that sort of error occur when I try to call a virtual-method using a dangling-pointer (to an object that had already been deleted). (calling methods on a dangling-pointer invokes undefined behavior, but one particular type of undefined behavior is: the runtime seeing the deconstructed-but-not-yet-overwritten vtable-pointer of the deleted object and acting on it) – Jeremy Friesner Aug 03 '22 at 01:37
  • The idea is, I don't get why MSVC just decides to not trap into the debugger. I think that's really bad on the part of Microsoft. I hate it. – iProgramInCpp Aug 03 '22 at 18:26
  • _" why MSVC just decides to not trap into the debugger"_ - The C++ standard leaves a lot to implementations of the standard. The language is so hard to understand that analyzing the logic behind what a programmer actually mean when using the language and what the diagnose should be is ... hard. – Ted Lyngmo Aug 08 '22 at 00:49
  • Alright, but it should trap into the debugger at least instead of spawning an asynchronous message box and leaving the application running until clicking OK... What the hell Microsoft!? – iProgramInCpp Aug 08 '22 at 08:26
  • This error is caused by calling a virtual function in an abstract base class through a pointer which is created by a cast to the type of the derived class, but is actually a pointer to the base class. This can occur when casting from a void* to a pointer to a class when the void* was created during the construction of the base class.I suggest you try to reinstall or update the CRT library, and this [link](https://answers.microsoft.com/en-us/windows/forum/all/runtime-error-program-cpr-r6025-pure-virtual/5829491a-b6d5-41a6-a381-789863e13e29) is also helpful. – Yujian Yao - MSFT Aug 10 '22 at 06:30
  • My issue with this error, and the reason I joined StackOverflow and created this post in the first place, is that it doesn't trap the debugger. I'm still looking for ways to fix it. – iProgramInCpp Aug 11 '22 at 12:50

0 Answers0