Dear All,
I’m trying to understand genreflex's behaviour, but had to realise that I understand it much less than I thought… I observed a very nasty issue in our code today that I was trying to reproduce in a standalone way, but couldn’t.
The issue is with one class that is something like this:
class TrickyClass {
...
private:
#ifndef NDEBUG
bool m_isInitialized = false;
#endif // not NDEBUG
...
};
The idea being that we would only use the m_isInitialized member in debug builds. So the cxx of the class also has a few #ifndef statements in it.
What I observed in our “full build” was that in a debug build I would get nasty runtime errors/crashes. Investigating this with Valgrind I found that the problem was that we create objects of this type (actually objects holding members of this type…) through its dictionary. And the dictionary doesn’t allocate memory of the right amount for this class in debug mode.
So I was trying to reproduce this issue with a simple example. But I’m just not able to. What I find is that for the class that I observed this on originally, the generated dictionary would only have these functions defined:
...
namespace ROOT {
static TClass *CPcLcLEgammaCalibrationAndSmearingAlg_Dictionary();
static void CPcLcLEgammaCalibrationAndSmearingAlg_TClassManip(TClass*);
static void delete_CPcLcLEgammaCalibrationAndSmearingAlg(void *p);
static void deleteArray_CPcLcLEgammaCalibrationAndSmearingAlg(void *p);
static void destruct_CPcLcLEgammaCalibrationAndSmearingAlg(void *p);
...
While in my “simple example” I would always get some additional functions as well.
...
namespace ROOT {
static TClass *MyClass_Dictionary();
static void MyClass_TClassManip(TClass*);
static void *new_MyClass(void *p = 0);
static void *newArray_MyClass(Long_t size, void *p);
static void delete_MyClass(void *p);
static void deleteArray_MyClass(void *p);
static void destruct_MyClass(void *p);
...
What would be the reason for this? Why does the dictionary for the CP::EgammaCalibrationAndSmearingAlg type not have new_ functions? It’s not an abstract type. ROOT is able to construct such objects through their dictionaries.
In any case, I suspect that I see the problem in our full build because of this. That the way that the dictionary allocates a new instance of this algorithm is different than how I try to allocate an instance of my test class in the standalone example.
For now we’ll just give up on using NDEBUG in the header of this class, but I’d still very much like to understand what is going wrong.
Cheers,
Attila
P.S. And yes, I did check that the NDEBUG flag is not provided to the genreflex call in our full build in debug mode.