1

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?

  • 2
    When was a memory leak detector last run on the code? do you run any static analysers on the code? – Surt Sep 12 '14 at 19:56
  • 2
    Sounds like heap corruption. There error is almost certainly not in the `memcpy` call. It could have happened long ago. – Jonathan Potter Sep 12 '14 at 19:58
  • The `memcpy()` is probably just identifying the problem. It sounds as if you have a major buffer overflow so that most of your stack was trashed by something (maybe this `memcpy()`) writing over the stack. This would probably mean you have an array on the stack (say of N elements) but your code is somehow guessing that there are M elements in the array (with M > N), and this is leading to trashing the useful information before the call to `memcpy()`. Since the debugger tries to use the trashed stack information, it can't be helpful because the damage has been done already. – Jonathan Leffler Sep 12 '14 at 20:10
  • Install "Application Verifier" and run it. It is a free debugging tool from Microsoft. It is available in the free "Windows Debugging SDK". It can help you find leaks and corruptions. The Windows 7 version and prior information can be found here at: http://msdn.microsoft.com/en-us/library/windows/desktop/dd371695(v=vs.85).aspx or you can just get the entire free Debugging SDK from http://msdn.microsoft.com/en-us/library/windows/hardware/ff551063(v=vs.85).aspx or from http://msdn.microsoft.com/en-US/windows/desktop/bg162891 . – StarPilot Sep 12 '14 at 21:15

1 Answers1

1

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?

Community
  • 1
  • 1
Carlo Wood
  • 5,648
  • 2
  • 35
  • 47
  • As it turned out, it was a bad string copy constructor resulting from a bad static cast. –  Oct 27 '14 at 15:18
  • Wait what? How can this happen without a stack trace? And is this specific to something in C++? I'm getting this as well... How do I even begin finding where the issue might be? – Joakim Aug 27 '15 at 09:28