unmanaged pointer in managed c++

  • Thread starter Thread starter waldo
  • Start date Start date
W

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;
 
waldo said:
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;
Click to expand...

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.
 
WebSnozz said:
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.
Click to expand...

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.
 
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.
Click to expand...

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???
 
waldo said:
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???
Click to expand...

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
 
waldo said:
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???
Click to expand...

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.
 
Thanks a million Ben!

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