Changes in lines that will not execute breaks the build !

I have this job of implementing a library that provides a file-sharing feature.

This has already happened twice:

First, in a string in an if-else path,开发者_JS百科 only the if path is being executed, but when i change a spelling in the else path, the software after a few minutes crashes in an std library. I verified with a debug attached that the lined changed was never being touched. When i reversed the change, it works nicely again.

Second, my software crashes on a std library again with the out-of-array check into a standard basic_string destructor.

I did everything, all library matched the _HAS_ITERATOR_DEBUGGING.

After 4 hours I discovered that the problematic file is TorrentFile.cpp/h.

If i add a function ( even though it is never called ), the program crashes at the end of that file, but if its not there, there's no bug. The code causing the problem:

std::vector<TorrentFileListPacket> TorrentFile::GetFileMap()
{
    std::vector<TorrentFileListPacket> vFiles;
    return vFiles;
};

If i comment this code out, the crash is gone.

This is really driving me crazy!

I've been a developer for 8 years, and I've never seen something like this before!

Additional Information

My memory is OK, I'm using Visual Studio 2010 with SP1 in Windows 7. The library is libTorrent from RasterBar and it links to boost. The software is using MFC.

---

This smells strongly of memory corruption in a totally different location from where you would expect from the crashes. Most likely adding and removing functions is changing the memory layout in such a way that causes the memory corruption's effects to be immediately visible or not.

Your best hope is something like Purify or Valgrind to hunt it down.

---

You probably want to make sure that all your object files and libraries are ABI compatible with each other.

Numerous compiler settings will change the ABI. Especially debug and release builds and iterator debugging. The struct layout for standard containers typically change when you enable iterator debugging (which I believe is on by default for all debug builds in msvc, and off for release builds).

So, if a single object file, static library or DLL that you link against is built with an incompatible configuration, you typically see very odd behaviors. With libtorrent you need to make sure you build the library with the same configuration as you link against it with. Many of the TORRENT_* defines will actually change some aspect of some struct layout or function call. Make sure you define the exact same set of those in your client as when building the library. One simple way of dealing with this problem is to simply pull all source files into your project and build everything together.

---

If you are using libtorrent as a DLL (or boost for that matter), are they compiled against the same C Run-Time?

Often when I run into this type of issue it is because I make a call into a library that was compiled with MinGW (which uses the CRT from VS6.0) or an older version of Visual Studio. If memory is allocated by the library and then free'd by your application, you will often get these types of errors in the destructor.

If you aren't sure, you can open the DLL in question in a tool like the Dependency Walker. Look for the dependency MSVCRT.DLL, MSVCR100.DLL, etc.