2009/5/30 Emil Dotchevski :

Long shot, but it looks like you have ABI conflict of some sort. Could you post a simple, complete program that demonstrates your problems?

Here is the complete sourcecode of a Win32 console application that reproduces my problem. And shame on me, I forgot to mention that my application as well as the Boost libraries uses STLport version 5.0.2 #define WIN32_LEAN_AND_MEAN // Exclude rarely-used stuff from Windows headers #include #include #include class MyBoostException : public boost::exception { public: MyBoostException() { /*do nothing*/ }; virtual ~MyBoostException() { /*do nothing*/ }; }; void DoSomething() { throw MyBoostException() << boost::throw_file( _T(__FILE__) ) << boost::throw_line( __LINE__ ) << boost::throw_function( _T("DoSomething()") ); } int _tmain( int argc, _TCHAR* argv[] ) { try { DoSomething(); } catch( MyBoostException& ex ) { boost::shared_ptr<const int> pLine = boost::get_error_infoboost::throw_line(ex); boost::shared_ptr pMethod = boost::get_error_infoboost::throw_function(ex); const char* sMethod = *pMethod; boost::shared_ptr pFile = boost::get_error_infoboost::throw_file(ex); const char* sFile= *pFile; std::string info = boost::diagnostic_information( ex ); const char* sString = info.c_str(); } return 0; }

2009/6/2 Emil Dotchevski :

I am puzzled, but here is another guess.

Boost::throw_line, boost::throw_function and boost::throw_file have special handling in Boost Exception; adding them to exceptions does not use anything from STL. So here is something to try: print *pLine, sMethod and sFile directly. If you get correct strings, then the problem could be in some interference between STLport and std::ostringstream. Step into boost::diagnostic_information and see what is passed into std::ostringstream's operator<<. If the data entering it is good but the output from .str() is bad, it's definitely an issue with STLport's installation.

It seems that std::ostringstream has nothing to do with my problems. But the STLport installation might still be the guilty party. I detected the source of annoyance within file 'get_error_info.hpp', at line 49 respectively 67, where a string wrapper instance is created: shared_ptr<strwrap> s(new strwrap(x.throw_function_)); respectively shared_ptr<strwrap> s(new strwrap(x.throw_file_)); Initialization of attribute 'str' (a std::string) within strwrap's c'tor, is the point where the null-termination get lost. For now I try to compile my application with a newer STLport version, respectively without any STLport, to see what happen. Progress will be reported soon...