Aubrey, Jason wrote:

Replies are at the end of this message: Aubrey, Jason wrote:

...

Hi,

When I run the following program it runs successfully but throws an exception during shutdown. I don't know why, but it seems that the call to boost::filesystem::file_size() is corrupting memory somehow. This example only shows the call to file_size() but I think I've seen similar trouble with other calls within boost::filesystem.

Am I doing something wrong here or is this a bug?

Regards, Jason Aubrey

----------------------

Environment: OS: Win2k Compiler: VS7.1 Boost: v1.33.1

----------------------

#include #include <fstream>

int main(int, char**) { // Create a file using namespace std; const string fileName("/temp/test.txt"); ofstream file; file.open(fileName.c_str()); const string message("this is a test"); file << message; file.close();

const boost::intmax_t fileSize = boost::filesystem::file_size(fileName);

if( fileSize != message.size() ) throw std::exception("Bad result");

return 0; }

Either I'm missing something, or...

file_size takes a path reference as its calling argument. You're passing a string. How does this even compile?

- Rush _______________________________________________

Thanks for the Reply Rush.

If I modify the above code to contain the following I still see the same behavior: const boost::filesystem::path filePath(fileName); const boost::intmax_t fileSize = boost::filesystem::file_size(filePath);

Regards, Jason Aubrey _______________________________________________

Would you be able to print out what the values of message.size() and fileSize are, right before you do that comparison?

Thanks, Lawrence Spector _______________________________________________

Both fileSize and message.size() are 14. The exception thrown is not a result of the if-block, but the result of a check by the runtime when it does its cleanup during program shutdown.

Hi Jason, Well, it's too bad that the Easy Answer wasn't the correct answer. :-) I made a console app using VS2005 and Boost 1.33.1, and used your exact code as my main routine. It just works. I also tried setting things up so that my debug build would link against the release version of the library, because the last person that was having filesystem problems had done that, but it just works in that case too. So I'm afraid that I can't reproduce your problem with my Windows setup. If you run your app under the debugger and break when it gets the error, can you tell what sort of object it's trying to delete by backtracking up the stack? That might give some hint about what's happening. Best regards, Rush