[LLVMdev] LLVM and the "static initialization order fiasco"

[Reid Spencer]

Hi Morten,

I ran into this with XPS which carefully avoids static initialization
and has its own operator new as well. However, there is little
motivation in the LLVM team to fix this, and for good reason. Several of
the feature of LLVM depend on static initialization but nothing in LLVM
depends on the order.

Most likely, you will have to do what I did: fix your operator new. It
is not "standard" to have an operator new that is only available within
the bounds of "main. You will need to override the various flavors of
::operator new and delete and ensure they are available both before and
after "main".

Others might have some more light on this subject.

Reid.
 
On Wed, 2004-11-10 at 03:10, Morten Ofstad wrote:
> Hello, I'm getting bitten by the "static initialization order fiasco"
> 
> http://www.parashift.com/c++-faq-lite/ctors.html#faq-10.12
> 
> The static data causing the problem is the static 
> TypeMap<PointerValType, PointerType> PointerTypes; and other typemaps. 
> The background is that in our product we are using an overridden new 
> operator to track memory allocations. This system is intialized at the 
> beginning of main(), and any 'new' before that will not be tracked. At 
> the end of main any memory which has leaked is reported and after the 
> end of main, any calls to 'delete' can only be deleting untracked 
> memory. This is working well as long as you're careful with static 
> objects, however the typemaps are intialized before main and the objects 
> they contain are created in main (tracked) but destroyed after main 
> together with the typemap. That means they end up being allocated by one 
> memory system and freed by another which is obviously not a good thing.
> 
> If there was some way for me to delete the types that have been 
> constructed before main exits, that would solve the problem... Most 
> other libraries have Init() and DeInit() functions instead of relying on 
> static initialization -- I will make something like this myself as a 
> temporary fix, but are there any opinions on a more long term solution?
> 
> m.
> 
> 
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041110/c9d0d87b/attachment.sig>