LUMIERA.clone/research/clang-static-init-2.cpp


#include "clang-static-init.hpp"

#include <iostream>

using std::cout;
using std::endl;


namespace test {
  
  
  int Subject::cnt = 0;
  
  Subject::Subject()
    {
      ++cnt;
      std::cout << "Subject("<<cnt<<")\n";
    }
   
  
  namespace {
      //
  }
  
  AccessPoint fab;
  
  
  Subject&
  fabricate()
  {
    return fab.get();
  }
  
  
} // namespace test
bughunt: extract a call sequence leading to a strange init error with Clang Observations: - the initial observation was that we get two instances of the config rules service - obviously this it is not the initialisation of a static variable accessed from multiple compilation units. But the access from two compilation units is crucial - we can exclude the effect of all other initialisation. It is in SingletonSubclass - we can exclude the effect of dynamic linking. Even two translation units linked statically exhibit the same problem rebuild this test case in the research area, to be able to verify with various compilers 2013-09-29 01:08:15 +02:00
bughunt: build testcase statically linked ...but still dynamically linking against the core lib But the actual template instantiations happen now within the two compilation units, which are linked statically. When looking into the symbol table, we can see that the static field is emitted two times readelf -W target/clang-static-init -s \| c++filt \|less 2013-09-30 00:42:27 +02:00			`#include "clang-static-init.hpp"`
bughunt: extract a call sequence leading to a strange init error with Clang Observations: - the initial observation was that we get two instances of the config rules service - obviously this it is not the initialisation of a static variable accessed from multiple compilation units. But the access from two compilation units is crucial - we can exclude the effect of all other initialisation. It is in SingletonSubclass - we can exclude the effect of dynamic linking. Even two translation units linked statically exhibit the same problem rebuild this test case in the research area, to be able to verify with various compilers 2013-09-29 01:08:15 +02:00
			`#include <iostream>`

			`using std::cout;`
			`using std::endl;`


			`namespace test {`


			`int Subject::cnt = 0;`

			`Subject::Subject()`
			`{`
			`++cnt;`
			`std::cout << "Subject("<<cnt<<")\n";`
			`}`


			`namespace {`
bughunt: attempt to rebuild the problematic structure stand-alone... --> MISS this is only a stripped-down version of the basic singleton, without the indirection. Unsurprisingly, this doesn't exhibit the problem yet 2013-10-06 17:37:01 +02:00			`//`
bughunt: extract a call sequence leading to a strange init error with Clang Observations: - the initial observation was that we get two instances of the config rules service - obviously this it is not the initialisation of a static variable accessed from multiple compilation units. But the access from two compilation units is crucial - we can exclude the effect of all other initialisation. It is in SingletonSubclass - we can exclude the effect of dynamic linking. Even two translation units linked statically exhibit the same problem rebuild this test case in the research area, to be able to verify with various compilers 2013-09-29 01:08:15 +02:00			`}`

bughunt: attempt to rebuild the problematic structure stand-alone... --> MISS this is only a stripped-down version of the basic singleton, without the indirection. Unsurprisingly, this doesn't exhibit the problem yet 2013-10-06 17:37:01 +02:00			`AccessPoint fab;`
bughunt: use a single SingletonSub instance in two compilation units --> HIT basically this reproduces the problem in a simplified setup. Especially note that we're going through a single instance of the factory, yet still this single instance 'sees' two different locations of the class static variable 2013-09-30 02:09:31 +02:00
bughunt: extract a call sequence leading to a strange init error with Clang Observations: - the initial observation was that we get two instances of the config rules service - obviously this it is not the initialisation of a static variable accessed from multiple compilation units. But the access from two compilation units is crucial - we can exclude the effect of all other initialisation. It is in SingletonSubclass - we can exclude the effect of dynamic linking. Even two translation units linked statically exhibit the same problem rebuild this test case in the research area, to be able to verify with various compilers 2013-09-29 01:08:15 +02:00
bughunt: replace the ConfigResolver with a direct instantiation of Singleton -> MISS thus not lib::Singleton is the culprit, it must be lib::SingletonSubclass 2013-09-30 00:58:39 +02:00			`Subject&`
bughunt: extract a call sequence leading to a strange init error with Clang Observations: - the initial observation was that we get two instances of the config rules service - obviously this it is not the initialisation of a static variable accessed from multiple compilation units. But the access from two compilation units is crucial - we can exclude the effect of all other initialisation. It is in SingletonSubclass - we can exclude the effect of dynamic linking. Even two translation units linked statically exhibit the same problem rebuild this test case in the research area, to be able to verify with various compilers 2013-09-29 01:08:15 +02:00			`fabricate()`
			`{`
bughunt: attempt to rebuild the problematic structure stand-alone... --> MISS this is only a stripped-down version of the basic singleton, without the indirection. Unsurprisingly, this doesn't exhibit the problem yet 2013-10-06 17:37:01 +02:00			`return fab.get();`
bughunt: extract a call sequence leading to a strange init error with Clang Observations: - the initial observation was that we get two instances of the config rules service - obviously this it is not the initialisation of a static variable accessed from multiple compilation units. But the access from two compilation units is crucial - we can exclude the effect of all other initialisation. It is in SingletonSubclass - we can exclude the effect of dynamic linking. Even two translation units linked statically exhibit the same problem rebuild this test case in the research area, to be able to verify with various compilers 2013-09-29 01:08:15 +02:00			`}`


bughunt: build testcase statically linked ...but still dynamically linking against the core lib But the actual template instantiations happen now within the two compilation units, which are linked statically. When looking into the symbol table, we can see that the static field is emitted two times readelf -W target/clang-static-init -s \| c++filt \|less 2013-09-30 00:42:27 +02:00			`} // namespace test`