7

I have the following line in my program that causes a run-time warning:

if (!is_directory("C:\\NGFMS_Debug\\Files") && !create_directories("C:\\NGFMS_Debug\\Files"))

The text of the warning is as so: "A buffer overrun has occurred in XXX.exe which has corrupted the program's internal state."

The warning comes in the call to "is_directory(...)". I'm guessing the space for the string isn't getting allocated, but I thought syntax like this was legal.

The is_directory function is a part of boost/filesystem.hpp and I am using the following namespaces:

using namespace boost;
using namespace boost::filesystem;
using namespace std;

This is getting compiled under VS2005 C++. Any ideas?

Update

I tried a couple different things and stepped through the code and here is what I found.

If I do this 

char* path_chars_c;
path_chars_c = "C:\\Debug\\Files";
string path_str_c(path_chars_c);

The variable path_chars_c contains the appropriate string, but the variable path_str_c contains garbage after initialization. So it appears that the string initialization is broken here. Has anyone ever seen this?

Ian
  • 4,169
  • 3
  • 37
  • 62
  • A buffer overflow does not cause an exception -- if you're actually seeing an exception then you need to provide more information. – ildjarn Feb 13 '12 at 21:26
  • @ildjarn I'm seeing a windows breakpoint I suppose. Post changed accordingly. – Ian Feb 13 '12 at 21:30
  • I'm confused. Is this a compiler warning? You should post the message verbatim. – Gabe Feb 13 '12 at 21:44
  • This is a run-time warning that says "A buffer overrun has occurred in XXX.exe which has corrupted the program's internal state." – Ian Feb 13 '12 at 21:46
  • @Ian: You need to run your program through a debugger. – Lightness Races in Orbit Feb 13 '12 at 21:51
  • Odds are, you've somehow trashed the heap or the stack. If you can't even create a simple string, odds are good that the heap or stack is corrupt. The error probably happened in some other code. – Nicol Bolas Feb 13 '12 at 21:55
  • @Nicol Actually Mr Edward Loper was correct. The DLL that the error was in was composed of 2 projects and 1 was compiled in debug mode while the other was not. Compiling both in debug mode fixed the issue. – Ian Feb 13 '12 at 22:14

1 Answers1

6

This is a surprising error -- that seems like a pretty standard use of boost::filesystem::is_directory(). Have you tried stepping into it w/ a debugger to see where the issue happens?

One (remote) possibility comes to mind -- if you are linking libraries that have NDEBUG enabled with libraries that have NDEBUG disabled, you can run into trouble. In particular, a few boost datatypes will allocate some extra debugging fields when debugging is turned on. So if an object gets created by one piece of code that thinks debugging is off, but then used by another piece of code that thinks debugging is on, then you can get random memory errors (such as buffer overflows).

Edward Loper
  • 15,374
  • 7
  • 43
  • 52
  • Wow, that was an extremely good guess. Making sure everything was compiled in DEBUG mode fixed it. – Ian Feb 13 '12 at 21:54