none
ASSERT when deleting a dialog pointer RRS feed

  • 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
    Monday, June 29, 2009 12:14 AM

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_»
    Monday, June 29, 2009 2:50 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.
    Monday, June 29, 2009 4:21 AM
    Moderator
  • 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,

    Jialiang Ge

    http://cfx.codeplex.com

     


    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.
    Monday, June 29, 2009 8:51 AM
    Moderator
  • 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
    Wednesday, July 8, 2009 7:07 PM

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_»
    Monday, June 29, 2009 2:50 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.
    Monday, June 29, 2009 4:21 AM
    Moderator
  • 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,

    Jialiang Ge

    http://cfx.codeplex.com

     


    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.
    Monday, June 29, 2009 8:51 AM
    Moderator
  • 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.
    Wednesday, July 8, 2009 8:23 AM
    Moderator
  • 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
    Wednesday, July 8, 2009 7:07 PM
  • 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
    Thursday, August 27, 2009 12:33 PM
  • 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.
    Monday, August 31, 2009 11:25 AM
    Moderator
  • 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()

    Thursday, September 3, 2009 7:01 AM
  • 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()


    Monday, September 7, 2009 7:25 AM
  • I  will suggest you create a new thread instead of asking a question in a thread which is already closed.

    Thanks

    Rupesh Shukla
    Wednesday, September 9, 2009 3:30 PM