From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2006-06-22 17:12:01
"Sean Huang" <huangsean_at_[hidden]> wrote in message
> ----- Original Message -----
> From: "Gennadiy Rozental" <gennadiy.rozental_at_[hidden]>
>> "Sean Huang" <huangsean_at_[hidden]> wrote in message
>>> Here is the scenario:
>>> A test case implemented as a class and the class uses
>>> boost::serialization in the destructor to serialize some objects.
>>> On windows, with both VC7.1 and VC8, I would get access violations and
>>> runtime-error - pure virtual function call. Turned out it is because
>>> cases are not destroyed until the unit test framework singleton instance
>>> goes away which happens only after the main returns.
>>> uses extensively function scope static objects and these objects are
>>> instantiated during program termination in this particular case. There
>>> some issues AFAICS:
>>> 1. function-scope static objects deletion order
>>> 2. At least with MSVC, atexit is called when a function-scope static
>>> is created. It seems that the implementation does not support calling
>>> when doexit is running. I took a quick glance at the standard but did
>>> find anything that mentions when atexit can be called.
>>> I was able to resolve the problem by forcing the deletion and recreation
>>> the static unit test framework singleton object but I am not sure if
>>> will be other consequences.
>> Above information does not give me a clear picture of what is going on.
>> Could you please post some example code, so I could comment more
> Here is an example:
> T's destructor will not be called. If there are too many static objects
> this (as in the case of boost::archive and boost::serialization), the
> program crashes with access violations because the CRT tries to realloc
> function list used by atexit().
> Hope this clarifies things a little.
I still do not see Boost.Test references. Could you please give an example
that shows the Boost Test involvement.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk