Answered by:
ASSERT when deleting a dialog pointer

Question
-
I have a windows mobile application and I have a class that is used to display items in a listbox called CFuncSelectItem.
I find that I get an ASSERT warning when I try to delete the pointer like so.
void CMatchDetails::OnGetNameButton()
{
CFuncSelectItem* pDlgList = new CFuncSelectItem();
if (pDlgList->DoModal() == IDOK)
{
m_sGlobalName = pDlgList->m_sSelect;
m_staticName.SetWindowText(m_sGlobalName );
}
delete pDlgList; <--ASSERT appears here
}
The ASSERT is:
Debug Assertion Failed:
Program:\ Program Files\ MyProgram\MyProgram.exe
C:Program FIles\Microsoft Visual Studio 8\VC\ce\atlmfc\include\atlsimpstr.h line 108
Expression: nRefs != 0
(Abort | Retry | Ignore).
When I hit ignore the program just freezes.
ANy ideas, what can I check in the debugger to throw more light on this problem. What should I be looking out for? What does the nRef message mean. I dont really want to post the whole code of the CFuncSelectItem class here.
Thanks
Answers
-
I'm guessing the assert has something to do with some CString manipulation you're doing probably in the destructor of the dialog class.And I really think you should go easy on the dynamic memory allocation stuff.For instance, the code in your posting uses new to create the dialog class.You should be creating that on the stack.
«_Superman_»- Marked as answer by jialge_msftMicrosoft employee, Moderator Monday, August 31, 2009 11:26 AM
-
Have you called CString::GetBuffer somewhere? If so then do remember to call ReleaseBuffer. Also why do you have to "new" allocate CFuncSelectItem, you can just create a local object since it's a modal dialog no?
Microsoft MVP - Visual C++
Blog: http://nibuthomas.com
Posts are provided as is without warranties or guaranties.- Marked as answer by jialge_msftMicrosoft employee, Moderator Monday, August 31, 2009 11:26 AM
-
Hello LearnerMan
> What does the nRef message mean.
nRefs represents the current reference count of the CStringData object. This value is used in determining how many string objects are sharing the same CStringData object. The assertion statement in discussion is thrown from the Release method of CStringData:
void Release() throw()
{
ATLASSERT( nRefs != 0 );
if( _AtlInterlockedDecrement( &nRefs ) <= 0 )
{
pStringMgr->Free( this );
}
}
(The code is copied from C:\Program FIles\Microsoft Visual Studio 8\VC\ce\atlmfc\include\atlsimpstr.h line 108)
In other words, nRefs is unexpectedly set to be 0. We need to find out when/where/how it was set.
> Any ideas, what can I check in the debugger to throw more light on this problem. What should I be looking out for?
My suggestion is to first find out the variable that holds the culprit CStringData struct, then search for all uses of the variable in your code to see whether there’s any misuse.
To find out the variable that holds the culprit CStringData, you can click “Retry” when you see the assert dialog. This will start up your JIT debugger (e.g. Visual Studio or windbg) to attach to the process. After the debugger is attached, open the call-stack window. (In Visual Studio, the call-stack window can be opened in Debug menu -> Windows -> Call Stack). The call-stack should look like this:
yourexe!ATL::CStringData::Release+0x26
…
yourexe!Your Code
…
The first part of the call-stack should belong to MFC/ATL CString(Data). Your own codes follow that part. Find the topmost line of your codes in the call-stack, and double click the line. You will be navigated to source code that corresponds to the stack frame, and the code line that throws the error is highlighted in the debugger. The line should also tell you the culprit variable holding the CStringData struct.
Next, please perform a search in your project for the variable, and list all its uses. Pay special attention to any possibility that the variable was double-freed or was corrupted somewhere.
Please try the above suggestion. If you have any questions, please feel free to tell me.
Regards,
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
Send us any feedback you have about the help from MSFT at fbmsdn@microsoft.com.- Proposed as answer by jialge_msftMicrosoft employee, Moderator Friday, July 17, 2009 5:32 AM
- Marked as answer by jialge_msftMicrosoft employee, Moderator Monday, August 31, 2009 11:26 AM
-
A Simple ans use pointer only when it is truly required . In your code there is no need to use pointer.Second why not perform exception handling inside your code to know the reason of your problem.whenever allocate memory to your pointer don't forget to check the condition whether memory is allocated to your pointer or not , and in last don't forget to Initialize your pointer .
Thanks
Rupesh Shukla- Marked as answer by jialge_msftMicrosoft employee, Moderator Monday, August 31, 2009 11:27 AM
All replies
-
I'm guessing the assert has something to do with some CString manipulation you're doing probably in the destructor of the dialog class.And I really think you should go easy on the dynamic memory allocation stuff.For instance, the code in your posting uses new to create the dialog class.You should be creating that on the stack.
«_Superman_»- Marked as answer by jialge_msftMicrosoft employee, Moderator Monday, August 31, 2009 11:26 AM
-
Have you called CString::GetBuffer somewhere? If so then do remember to call ReleaseBuffer. Also why do you have to "new" allocate CFuncSelectItem, you can just create a local object since it's a modal dialog no?
Microsoft MVP - Visual C++
Blog: http://nibuthomas.com
Posts are provided as is without warranties or guaranties.- Marked as answer by jialge_msftMicrosoft employee, Moderator Monday, August 31, 2009 11:26 AM
-
Hello LearnerMan
> What does the nRef message mean.
nRefs represents the current reference count of the CStringData object. This value is used in determining how many string objects are sharing the same CStringData object. The assertion statement in discussion is thrown from the Release method of CStringData:
void Release() throw()
{
ATLASSERT( nRefs != 0 );
if( _AtlInterlockedDecrement( &nRefs ) <= 0 )
{
pStringMgr->Free( this );
}
}
(The code is copied from C:\Program FIles\Microsoft Visual Studio 8\VC\ce\atlmfc\include\atlsimpstr.h line 108)
In other words, nRefs is unexpectedly set to be 0. We need to find out when/where/how it was set.
> Any ideas, what can I check in the debugger to throw more light on this problem. What should I be looking out for?
My suggestion is to first find out the variable that holds the culprit CStringData struct, then search for all uses of the variable in your code to see whether there’s any misuse.
To find out the variable that holds the culprit CStringData, you can click “Retry” when you see the assert dialog. This will start up your JIT debugger (e.g. Visual Studio or windbg) to attach to the process. After the debugger is attached, open the call-stack window. (In Visual Studio, the call-stack window can be opened in Debug menu -> Windows -> Call Stack). The call-stack should look like this:
yourexe!ATL::CStringData::Release+0x26
…
yourexe!Your Code
…
The first part of the call-stack should belong to MFC/ATL CString(Data). Your own codes follow that part. Find the topmost line of your codes in the call-stack, and double click the line. You will be navigated to source code that corresponds to the stack frame, and the code line that throws the error is highlighted in the debugger. The line should also tell you the culprit variable holding the CStringData struct.
Next, please perform a search in your project for the variable, and list all its uses. Pay special attention to any possibility that the variable was double-freed or was corrupted somewhere.
Please try the above suggestion. If you have any questions, please feel free to tell me.
Regards,
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
Send us any feedback you have about the help from MSFT at fbmsdn@microsoft.com.- Proposed as answer by jialge_msftMicrosoft employee, Moderator Friday, July 17, 2009 5:32 AM
- Marked as answer by jialge_msftMicrosoft employee, Moderator Monday, August 31, 2009 11:26 AM
-
Hello
How are you? I'm writing to check the current status of the issue on your side. Were the suggestions helpful to you? If you have any questions, please feel free to tell me.
Have a nice day!
Regards,
Jialiang Ge
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
Send us any feedback you have about the help from MSFT at fbmsdn@microsoft.com. -
A Simple ans use pointer only when it is truly required . In your code there is no need to use pointer.Second why not perform exception handling inside your code to know the reason of your problem.whenever allocate memory to your pointer don't forget to check the condition whether memory is allocated to your pointer or not , and in last don't forget to Initialize your pointer .
Thanks
Rupesh Shukla- Marked as answer by jialge_msftMicrosoft employee, Moderator Monday, August 31, 2009 11:27 AM
-
Actually in one my project some times I am getting the assertion nRef!=0 and nRef>0 but rather inconsistently . Call stack is not going to the exact problem location. and I am not getting yourexe!ATL::CStringData::Release+0x26 as the The first part of the call-stack but it is showing mfc80.dll. How to trace where is the real Csting variable causing this assertion.
Thanks in Advance
Sudhakar -
Hello Sudhakar
> How to trace where is the real Csting variable causing this assertion.
The callstack can propably tell you the culprit object. In the call stack, before CStringData::Release is called, what do you see? Is it a string object that is releasing itself?
Regards,
Jialiang Ge
Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us. -
My Question is why some times only it is coming /reproducible. this nRef !=0 assertion is coming some times only ..why..? How can i reproducible constantly to fix it..
I got call stack like this .but it is not pointing to the correct culprit variable..?
mfc80d.dll!78211e8e()
[Frames below may be incorrect and/or missing, no symbols loaded for mfc80d.dll]
mfc80d.dll!7821571c()
mfc80d.dll!78216fcf()
CDTestSetup.dll!CMap<int,int &,ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> >>,ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > > &>::CPair::~CPair() + 0x31 bytes C++
CDTestSetup.dll!CMap<int,int &,ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> >>,ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > > &>::CAssoc::~CAssoc() + 0x2b bytes C++
> CDTestSetup.dll!CMap<int,int &,ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> >>,ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > > &>::RemoveAll() Line 1466 C++
CDTestSetup.dll!CMap<int,int &,ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> >>,ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > > &>::~CMap<int,int &,ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> >
>,ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > > &>() Line 1484 C++
CDTestSetup.dll!CDlgCDDataCorrelation::~CDlgCDDataCorrelation() Line 54 + 0x5e bytes C++
CDTestSetup.dll!CDlgCDDataCorrelation::`scalar deleting destructor'() + 0x2b bytes C++
RECommon.dll!005def53()
ElementCommonLib.dll!0721d7f7() -
My Question is why some times only it is coming /reproducible. this nRef !=0 assertion is coming some times only ..why..? How can i reproducible constantly to fix it..
I got call stack like this .but it is not pointing to the correct culprit variable..?
mfc80d.dll!78211e8e()
[Frames below may be incorrect and/or missing, no symbols loaded for mfc80d.dll]
mfc80d.dll!7821571c()
mfc80d.dll!78216fcf()
CDTestSetup.dll!CMap<int,int &,ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> >>,ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > > &>::CPair::~CPair() + 0x31 bytes C++
CDTestSetup.dll!CMap<int,int &,ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> >>,ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > > &>::CAssoc::~CAssoc() + 0x2b bytes C++
> CDTestSetup.dll!CMap<int,int &,ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> >>,ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > > &>::RemoveAll() Line 1466 C++
CDTestSetup.dll!CMap<int,int &,ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> >>,ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > > &>::~CMap<int,int &,ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> >
>,ATL::CStringT<char,StrTraitMFC_DLL<char,ATL::ChTraitsCRT<char> > > &>() Line 1484 C++
CDTestSetup.dll!CDlgCDDataCorrelation::~CDlgCDDataCorrelation() Line 54 + 0x5e bytes C++
CDTestSetup.dll!CDlgCDDataCorrelation::`scalar deleting destructor'() + 0x2b bytes C++
RECommon.dll!005def53()
ElementCommonLib.dll!0721d7f7() -