unmanaged pointer in managed c++

[waldo]

Hi, i'm new to this stuff so please excuse my lack of understanding!!!
I've got an unmanaged class called Category and a coresponding managed
class, also called Category (shown at the end of this message)... I can
create and manipulate the class successfully in c#, but it crashes and
i get the following error message when "delete m_pCategory;" is called
in the Finalize() :

Debug Assertion Failed!
File:dbgdel.cpp
Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)

Any ideas what could be causing this??? Any help is greatly
appreciated:

/// <summary>Constructor</summary>
Category::Category(Utils::Category* pCategory) :
m_pCategory(pCategory)
{

}

/// <summary>Destructor.</summary>
Category::~Category()
{
delete m_pCategory;
m_pCategory = NULL;

}

/// <summary>Finalize.</summary>
Category::!Category()
{
delete m_pCategory;
m_pCategory = NULL;

 

[WebSnozz]

Hi, i'm new to this stuff so please excuse my lack of understanding!!!
I've got an unmanaged class called Category and a coresponding managed
class, also called Category (shown at the end of this message)... I can
create and manipulate the class successfully in c#, but it crashes and
i get the following error message when "delete m_pCategory;" is called
in the Finalize() :

Debug Assertion Failed!
File:dbgdel.cpp
Expression: _BLOCK_TYPE_IS_VALID(pHead->nBlockUse)

Any ideas what could be causing this??? Any help is greatly
appreciated:

/// <summary>Constructor</summary>
Category::Category(Utils::Category* pCategory) :
m_pCategory(pCategory)
{

}

/// <summary>Destructor.</summary>
Category::~Category()
{
delete m_pCategory;
m_pCategory = NULL;

}

/// <summary>Finalize.</summary>
Category::!Category()
{
delete m_pCategory;
m_pCategory = NULL;

All the examples I've seen using a different class name for the managed
and unmanaged classes. I guess if they are in different name spaces,
then you can disambiguate them easily enough, but it might be better to
use different class names while you are learning.

What I'd like to see is how you declared m_pCategory. I think this
should be declared as a pointer to the unmanaged type, but if both
classes are named Category, then it may be thinking that in the context
of usage, you are referring to the managed Class. If that is the case,
then I don't think you can perform delete on m_pCategory because it
would be a amanged type. I may be very wrong, as I am just learning,
but I would strongly suggest you try using different names for the
classes as a test, to ensure that m_pCatogory is declared as an
UnmanagedCategory, since it points to an unmanaged type.

 

[Ben Voigt]

All the examples I've seen using a different class name for the managed
and unmanaged classes. I guess if they are in different name spaces,
then you can disambiguate them easily enough, but it might be better to
use different class names while you are learning.

What I'd like to see is how you declared m_pCategory. I think this
should be declared as a pointer to the unmanaged type, but if both
classes are named Category, then it may be thinking that in the context
of usage, you are referring to the managed Class. If that is the case,
then I don't think you can perform delete on m_pCategory because it
would be a amanged type. I may be very wrong, as I am just learning,
but I would strongly suggest you try using different names for the
classes as a test, to ensure that m_pCatogory is declared as an
UnmanagedCategory, since it points to an unmanaged type.

True, but that would show up as a compile-time error.

What I want to see is the call to Category::Category(Utils::Category*). If
the argument is coming from anything but the return value of scalar new
Utils::Category(...) you will see this type of misbehavior when you delete.
My guess is the Utils::Category was created on the stack, inside another
object, or using the array new operator.

 

[waldo]

True, but that would show up as a compile-time error.

What I want to see is the call to Category::Category(Utils::Category*). If
the argument is coming from anything but the return value of scalar new
Utils::Category(...) you will see this type of misbehavior when you delete.
My guess is the Utils::Category was created on the stack, inside another
object, or using the array new operator.

Yes, the Utils::Category was created inside the constructor of another
object called RDConfig, as shown below:

RDConfig::RDConfig() :
Category(new RD::Utils::RDConfig())
{
m_pConfig = reinterpret_cast<RD::Utils::RDConfig*>(m_pCategory);
}


And in the unmanaged side of things, RDConfig is derived from
Category... Any ideas???

 

[Marcus Heege]

Yes, the Utils::Category was created inside the constructor of another
object called RDConfig, as shown below:

RDConfig::RDConfig() :
Category(new RD::Utils::RDConfig())
{
m_pConfig = reinterpret_cast<RD::Utils::RDConfig*>(m_pCategory);
}


And in the unmanaged side of things, RDConfig is derived from
Category... Any ideas???

The assertion you mention occurs when an object is deleted twice. Given your
design, chances are good that this is the case:
* the object is created and deleted in unrelated places:
it is created in the RDConfig constructor and deleted in the Utils::Config
destructor
* further unrelated pointers (m_pConfig) refer to the object

I would set a breakpoint in the Category destructor and see when it is
called.
Then I would run without the breakpoint and inspect the callstack where the
assertion fails.
Chances are good that this gives you the locations of both deletions of the
category object.

Furthermore, I would change the design, so that the object is created and
destroyed in one class.

Marcus

 

[Ben Voigt]

Yes, the Utils::Category was created inside the constructor of another
object called RDConfig, as shown below:

RDConfig::RDConfig() :
Category(new RD::Utils::RDConfig())
{
m_pConfig = reinterpret_cast<RD::Utils::RDConfig*>(m_pCategory);
}


And in the unmanaged side of things, RDConfig is derived from
Category... Any ideas???

Since it's a base class, it's constructed in the same fashion as RDConfig...
so where is RDConfig constructed? Also you are deleting virtually, so you
should make sure Utils::Category has a virtual destructor.

 

[waldo]

Thanks a million Ben!

My destructor wasn't virtual, now everything seems to be running
smoothly! Have a great weekend... Thanks again

 

[waldo]

Actually, thanks everybody for all your help