On Wed, Jan 30, 2008 at 06:38:34PM +0100, Joaquín Mª López Muñoz wrote:
Jens Seidel ha escrito:
On Wed, Jan 30, 2008 at 01:41:15PM +0000, Martin Fisher wrote:
Using the boost_1_35_0 svn library download and Visual C++ 2008 Express edition. Originally compiled as a CLR program. Recompiling using native Win32 still gives a crash during program termination - in atomic_count_win32.hpp in operator-- (BOOST_INTERLOCKED_DECREMENT) Unhandled exception at 0x010752b9 in fly2.exe: 0xC0000005: Access violation writing location 0x00779040.
There is indeed a bug somewhere. I could reproduce it on Linux which doesn't suffer from CLR/libc/... mess. I just compiled it (code from trunk) and it crashes. valgrind reports:
I could also reproduce it here, and found the reason for the crash. Please follow me:
And this is the problem: when the factory is destroyed, there are still flyweight objects around (those in vec), when there should be none, and on vec's destruction time the flyweight objects point to deallocated memory, hence the crash.
This is solved by forcing boost::flyweight<string> static initialization before that of vec:
boost::flyweights::flyweight<string>::initializer init; vector<boost::flyweights::flyweight<string> > vec;
So that static initialization order is correct. Could you please try the fix?
Right. valgrind does no longer complain.
This is a fundamental issue for which I see no easy *automatic* fix upon first reflection, other than documenting very clearly the situations in which it can arise. Comments and suggestions welcome.
Maybe it is possible to add an assert somewhere, so that at least debugging is simplified? Not everyone reads documentation carefully. Thanks, Jens