Hi,

I'm trying to find a bug in my game that causes it to crash on Windows 7. It crashes (almost) reliably when I do a specific thing in the game, but only on Windows 7 and only in the release build (without debug heap). It's some access violation reading from address 0000 0xxxx xxxx xxxx (it's always those 5 0's and a "random" number, weird). I'm testing my game on Windows 10 and this never happened in months (or years). On Windows 7, it crashed randomly and when I looked at it I actually found 2 problems and fixed them and now it crashes more often.

The problem with the error is: The game crashes at some point in time when I allocate or free memory in a different thread. I even tried to write code that causes such an error (to help me locate it) but everything I try makes it crash immediately.

How do I find the source of such an error? I would use the debug build but it just doesn't crash in the debug build. And I can't go through 50K lines of code.

I'm using several libraries but I doubt it's one of those. Their behavior shouldn't change on a different version of Windows.

Thanks in advance for your help!

Sounds like an irritated heap. If it was Linux and debug info was available i'd suggest to valgrind it ... ?

Edit: that may find such a corruption even on a different platform. A stray pointer is a stray pointer, in Windows 7 and 10 ... but i am just guessing ... maybe the offending code is only executed on Win 7 ...

20 minutes ago, Green_Baron said:

Sounds like an irritated heap. If it was Linux and debug info was available i'd suggest to valgrind it ... ?

I do have debug symbols but no debug heap and the code is optimized. I don't know, I have never done this before because I didn't need it. I guess now I need it.

Edit: I think I nailed it down to the GUI. It doesn't crash when I disable everything but the menu. Now I just need to find out which part causes the crash, good thing there are only about 20K lines of code for the GUI...

I found the problem, it was a small error on line 4078... I actually read from something that was deleted. That was pretty old code, it's weird that I never had a problem before.

I don't even know why I'm doing it that way, it makes no sense. I changed it so it can't happen anymore.

23 minutes ago, Wyrframe said:

... and that would corroborate it. You might feel like the code is "fixed", but you should reconsider from a design perspective how you even reached that point.

By being inexperienced when I wrote that code 3 to 4 years ago. It is actually fixed and I made sure this won't happen again.

23 minutes ago, Wyrframe said:

In particular, if you're using C++11 or C++17, and your application code includes any uses of the new/delete operators... you probably have a bug you haven't spotted yet

I'm actually using new to initialize smart pointers because Visual Studio doesn't show the constructor arguments when I use std::make_unique etc. I don't see that as a problem though. I'm open for suggestions as I have the same problem when I use emplace() or emplace_back() on their respective containers, I would really like VS to show what constructor options I have.

23 minutes ago, Wyrframe said:

In all seriousness, when fixing one bug causes two more to raise their heads, that suggests to me that the act of fixing the logic or design failure which induced the one bug, you also produced the side-effect of scraping away the crud which was hiding the other bugs...

It actually just made the same bug cause a crash more often because something changed. Any change could have caused that, it just happened to be another bug fix. It's weird that it didn't crash on Windows 10 on 3 different computers though, it really should have crashed at least sometimes.

23 minutes ago, Wyrframe said:

but that doesn't mean you have to keep the "new T(" prefix

Yes, but there is no point in changing it, doing that just wastes time.

23 minutes ago, Wyrframe said:

`.emplace_back(T(...))`

Oh, yeah, I could write the type and then remove it afterwards but I'm rarely using any complex types in containers anyway, most of the time I use basic types like int or string or pointers as data types. Maybe it's because of the missing autocomplete. I could really need some features to speed things up in general, e.g. I often use tuple because it's faster than writing a struct/class with 3 data members, including a constructor if I want VS to show the constructor arguments, it doesn't do that if I use "{}" for initialization.

I'd suggest enabling page heap mode, which tends to make heap corruption bugs crash quicker, and therefore makes them easier to debug.

You can enable it with the gflags tool, which is part of Debugging Tools for Windows: https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/

https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/gflags-and-pageheap