Search code examples
c++sfmlvisual-studio-debuggingmemcpy

Occasional crash from memcpy which I am not using in my program directly


I am working on the largest project I've ever worked on, and I've never debugged something like this, so I don't know where to get started.

Some info on the crash: I am using Visual Studio, and the debugger is completely useless. The only information it gives me is that it appears to be happening during a call to "memcpy". The call stack is completely empty except for the memcpy function, and the local variables are listed but it does not have values for any of them.

It happens occasionally on any computer.

It does not ALWAYS happen under any (known) condition, but it only ever happens under a few conditions. In particular it only happens when a particular type of object is destroyed, although that's not necessarily the direct cause, and investigating the destruction process has not been helpful.

A little more about the project: It is a game using SFML 2.0, linked statically. I am not calling memcpy anywhere in my own code.

Some questions: Where could the call to memcpy be coming from? Is it in SFML or elsewhere? How do I (using visual studio) get more information on a crash when the debugger isn't working?


Solution

  • This is an answer to "Where could the call to memcpy be coming from?"

    In most cases this is the result of a call to the copy constructor of std::string with a this pointer of NULL, or a string operation on an already destructed string. This string can be a member of a class of you, of course.

    This in itself won't help you to find the problem when the project is really large. However, you can almost certainly assume that you are using a reference or pointer (or iterator) to a custom object that is already destructed. A most straightforward way to find this access would be by running your program, compiled without optimization and with debug info, in valgrind. Unfortunately that isn't available for windows (see Is there a good Valgrind substitute for Windows?).

    The main problem here seems to be that you aren't even getting a backtrace, because that would give a strong hint to where to look into, at least. I'm not familiar with windows though, so I can only guess what is the cause of that. Are you sure you have everything compiled with debug info?