Cpv Declarations of types with constructors may induce 'static initialization order fiasco'

[PhilMiller]

Original issue: https://charm.cs.illinois.edu/redmine/issues/1337

---

The following Cpv declarations in C++ code instantiate objects of types that have constructors. Those constructors must be called during program startup, before main(). Their potential to allocate memory and reference other entities that may not have been initialized is a hazard. They should be converted to pointers to those types where appropriate, or otherwise made safe.

typedef CkHashtableT<CkHashtableAdaptorT<unsigned int>, CkCallback*> threadCB_t;
src/ck-core/ckcallback.C:CpvStaticDeclare(threadCB_t, threadCBs);

// class defs in blue_impl.h
src/langs/bluegene/blue.C:CpvDeclare(BGMach, bgMach);
src/langs/bluegene/blue.C:CpvDeclare(SimState, simState);

// class def in eventID.h
src/libs/ck-libs/pose/pose.C:CpvDeclare(eventID, theEventID);

tests/charm++/xcastredn/convMsgHandlers.C:CpvDeclare(std::vector<MyChareArray*>, localElems);

[PhilMiller]

Original date: 2016-12-31 02:46:03

---

https://charm.cs.illinois.edu/gerrit/2093 https://github.com/UIUC-PPL/charm/commit/67c6a421bccf7b009a296bb9e1e79955688c0232 Fix for the ckcallback case.

[stwhite91]

Original date: 2017-01-02 16:53:50

---

Fix for conv-ldb/topology case: https://charm.cs.illinois.edu/gerrit/#/c/2094/ https://github.com/UIUC-PPL/charm/commit/f72ff34cacd7f1d90ddc613cc1ef6368d92975ba

The rest of these are probably lower priority, being in libs/, langs/, and tests/

[ericjbohm]

Original date: 2017-01-11 19:24:48

---

Shifting to low priority as most of these are in code that is more likely to be eliminated than to become important.

[stwhite91]

Original date: 2017-01-17 16:26:25

---

Found another static variable of complex type in src/conv-core/cputopology.C: static CpuTopology cpuTopo;

Edit: nvm, CpuTopology has no constructor.

[ericjbohm]

Original date: 2018-03-14 17:16:13

---

no known use cases to justify making this a release 6.9.1 target