Back to General and Gameplay Programming

Destructor in vector called too often

Julian Watzinger · 2014-08-21T09:52:48

Hello, I recently experienced a very strange crash, which after inspecting further turned out to be caused by the destructor of a class being called one time too often in a certain vector creation. I havn't been able to fully determine the excact reason this is happening, so I hope some of you guys has a better idea of what could be going on. I'm using VS2013. This is the code that crashes: const ecs::ComponentDeclaration& Sprite::GenerateDeclaration(void) { const ecs::ComponentDeclaration::AttributeVector vAttributes = { { L"Texture", core::VariableType::STRING, offsetof(Sprite, stTexture), onSetTexture }, { L"Blending", core::VariableType::INT, offsetof(Sprite, blend) }, }; // this line here static const ecs::ComponentDeclaration declaration(L"Sprite", vAttributes); return declaration; } The crash happens in the commented line, so appearently in the vector construction. Let me show you all related code: struct ACCLIMATE_API ComponentDeclaration { public: typedef std::vector<AttributeDeclaration> AttributeVector; //... } This is the declaration of the vector. struct ACCLIMATE_API AttributeDeclaration { typedef void(*SetCallback)(BaseComponent& component); AttributeDeclaration(const std::wstring& stName, core::VariableType type, size_t offset, SetCallback pCallback = nullptr); std::wstring stName; size_t offset; SetCallback pCallback; ICustomComponentAttributes* pCustom; private: core::Variable m_default; }; AttributeDeclaration::AttributeDeclaration(const std::wstring& stName, core::VariableType type, size_t offset, SetCallback pCallback) : stName(stName), pCallback(pCallback), m_default(type, false), pCustom(nullptr) { } Thats the class that is being stored, with all related variables/methods. It stores a core::Variable class, which acts like a semi-variant data-container, which is defined as follows: class ACCLIMATE_API Variable { public: static const unsigned int NO_OBJECT = -1; Variable(VariableType type, bool isArray); Variable(const Variable& variable); Variable(Variable&& variable); ~Variable(void); Variable& operator=(const Variable& variable); Variable& operator=(Variable&& variable); private: void* m_pData; VariableType m_type; bool m_isArray; unsigned int m_objectType; }; Variable::Variable(VariableType type, bool isArray) : m_type(type), m_isArray(isArray), m_objectType(NO_OBJECT), m_pData(nullptr) { ACL_ASSERT(m_type != VariableType::OBJECT); if(type != VariableType::UNKNOWN) m_pData = CallByTypeNoObject<newData, void*>(); } Variable::Variable(const Variable& variable) : m_type(variable.m_type), m_isArray(variable.m_isArray), m_objectType(variable.m_objectType) { m_pData = CopyData(variable.m_pData); } Variable::Variable(Variable&& variable) : m_type(variable.m_type), m_isArray(variable.m_isArray), m_objectType(variable.m_objectType) { m_pData = variable.m_pData; variable.m_pData = nullptr; variable.m_type = VariableType::UNKNOWN; variable.m_objectType = NO_OBJECT; } Variable::~Variable(void) { // just for simplicities sake - the actual deletion of the correct type is normally handled delete m_pData; } Variable& Variable::operator=(const Variable& variable) { if(this != &variable) { m_type = variable.m_type; m_isArray = variable.m_isArray; m_objectType = variable.m_objectType; DeleteData(); m_pData = CopyData(variable.m_pData); } return *this; } Variable& Variable::operator=(Variable&& variable) { if(this != &variable) { m_type = variable.m_type; m_isArray = variable.m_isArray; m_objectType = variable.m_objectType; m_pData = variable.m_pData; variable.m_pData = nullptr; variable.m_type = VariableType::UNKNOWN; variable.m_objectType = NO_OBJECT; } return *this; } Now the crash happens inside this classes ctor. Obviously, m_pData is destroyed more then once. The call hierachy looks as follows: - ctor of first line is being called (line in the first code snipped) - ctor for second line is being called - copy-ctor is called from the object of the first line - copy-ctor is called from the object of the second line - Destructor is called on the first object - Destructor is called on the second object - Destructor is called on the second object again - crash! Now the reason I know that the destructor is called again, and not m_pData is somehow deleted twice is that by setting m_pData to nullptr in the destructor, the crash resolves. Also note that it is probably not an issue with the Variable-class, as the void* m_pData has already been part of the AttributeDeclaration-class before, as well as part of some other class. _____________________________________________________ So, thats about all the information I can give. I can't make any sense of the vector-code, so debugging it further is rather out of the question. My question is now: Does someone see something obviously wrong, or knows/has some idea what is going on? Appearently I *could* fix it by simply putting in the nullptr-set in the ctor, but thats way to hackish and obviously just hides the problem. One thing I find interesting is that the move-ctor isn't called, as it is almost always when dealing with this kind of vector-emplacement, maybe thats related to the problem?

General and Gameplay Programming Programming

Started by Juliean August 19, 2014 08:29 AM

26 comments, last by Juliean 9 years, 8 months ago

Aardvajk

13,217

August 20, 2014 09:36 PM

I just tested your code with GCC 4.7.2 (Windows)


AttributeDeclartion() called.
AttributeDeclartion() called.
AttributeDeclartion(const AttributeDeclaration& decl) called with this: 8595680
and decl: 2686698.
AttributeDeclartion(const AttributeDeclaration& decl) called with this: 8595681
and decl: 2686699.
~AttributeDeclartion() called with this: 2686699.
~AttributeDeclartion() called with this: 2686698.
Initializing vector done.
~AttributeDeclartion() called with this: 8595680.
~AttributeDeclartion() called with this: 8595681.
Press <RETURN> to close this window...

So no duplicate destruction of the same object in there.

So perhaps this is a bug with initializer lists in VC, I dunno. Are you seeing the destructor message with the same value for "this" more than once in your output?

journal | website | twitter | youtube

Juliean

7,343

Author

August 20, 2014 10:21 PM

So no duplicate destruction of the same object in there.

So perhaps this is a bug with initializer lists in VC, I dunno. Are you seeing the destructor message with the same value for "this" more than once in your output?

Huh, thats weird. For me it actually completly looks like:


AttributeDeclartion() called.
AttributeDeclartion() called.
AttributeDeclartion(const AttributeDeclaration& decl) called with this: 8595680
and decl: 2686698.
AttributeDeclartion(const AttributeDeclaration& decl) called with this: 8595681
and decl: 2686699.
~AttributeDeclartion() called with this: 2686699.
~AttributeDeclartion() called with this: 2686698.
~AttributeDeclartion() called with this: 2686698. // thats the "faulty" line
Initializing vector done.
~AttributeDeclartion() called with this: 8595680.
~AttributeDeclartion() called with this: 8595681.
Press <RETURN> to close this window...

I actually found a ticket that states something about a memory leak in that initializer list in VC that should have been fixed some time ago. So maybe some over-enthusiastic programmer fixed the leak but also caused this double deletion. Don't know, based on that it doesn't happens in GCC I might as well post it to the VC-people, maybe someone there has greater insight to the actual problem.

Two things I notice about your example code (I don't have MSVC2013 on hand to test initializer lists at the moment):
1. By adding the string to the constructor you disabled the default constructor. Does the bug go away if you have a parameter of a different type? (Try with a POD like int, and a non-POD like, I dunno, std::shared_ptr<int>)
2. You don't have an assignment operator, so the compiler probably generated one for you. Add it in with matching debug output to see if an extra object is being generated and assigned to to match your destructor call. Or add it in as =delete and see if the compiler errors.

1. Yes! As I (at least I though I) mentioned it only happens with the string-type argument. Int, float bool, Class* all work. I didn't test it with other classes references which are implicitely created, might be worth a check though.

2. As I already stated multiple times, none of those operators are called in the code in question here. It would be a legit query, but doesn't mean anything here really due to this fact ;) Also, in my minimal test case, the class doesn't have any state at all, so there would be no point of a copy/move-operator in the first place... neigther is there for a copy-ctor, its just there to assist in debug-ouput. ;)

Aardvajk

13,217

August 21, 2014 07:13 AM

Not sure. Either:

a) There is a bug in VC

b) This program is relying on some undefined behaviour I'm not spotting that just happens to work with GCC

I suspect the former since its such a simple program fragment.

journal | website | twitter | youtube

Juliean

7,343

Author

August 21, 2014 08:56 AM

Not sure. Either:

a) There is a bug in VC

b) This program is relying on some undefined behaviour I'm not spotting that just happens to work with GCC

I suspect the former since its such a simple program fragment.

Probably the former, since every working online-compiler I could find, most of them based on GCC or similar, worked as intented. I'll report the appearent bug to Microsoft and post here again with the answer. Would still be nice though if anybody with visual studio 2013 or the 2012 November compiler CTP could also test the code and confirm that this is happening for him too.

lwm

2,518

August 21, 2014 09:21 AM

Would still be nice though if anybody with visual studio 2013 or the 2012 November compiler CTP could also test the code and confirm that this is happening for him too.

I'm sorry to say that I can't reproduce the problem with Visual Studio 2013 Update 2.

current project: Roa

Juliean

7,343

Author

August 21, 2014 09:26 AM

I'm sorry to say that I can't reproduce the problem with Visual Studio 2013 Update 2.

Dafuq? Ok, now I'm totally cursious. I'll double-check to see if I have the latest updates. I'll also see if I get to test it on another PC. Thanks for testing!

EDIT: So on this PC with a fresh installation of Visual Studio 2013 Express (Ultimate at my regular PC) from the online-installer about 3 weeks ago, it also happens. Don't really see if Update 2 is installed, but I can install update 3, which I will do to see if this is really related to this.

Aardvajk

13,217

August 21, 2014 09:48 AM

Just a thought, but try changing the optimization settings. At work we've found some bugs in GCC (reported) using -O3 and had to manually add the flags -O3 adds minus the one that was causing the issue.

journal | website | twitter | youtube

Juliean

7,343

Author

August 21, 2014 09:52 AM

Just a thought, but try changing the optimization settings. At work we've found some bugs in GCC (reported) using -O3 and had to manually add the flags -O3 adds minus the one that was causing the issue.

You where right. Totally doesn't happen in release mode. So now all I have to do is find the relevant setting and report it to microsoft. I quess I'll just #ifdef the nullptr-set for debug mode until they fix it, but its really something that shouldn't be happending.

EDIT: Ok, now it isn't happening at all anymore. Appears he just didn't compile after starting VS with the update 3, quess it was fixed in one of the updates. Going to confirm this on my home-PC, but I'm optimistic (even though I swear I was on the most recent update, weird). Thanks all for the help though!

Destructor in vector called too often

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Destructor in vector called too often

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines