Assert help wanted
Alec Ross
The environment is a codebase of (potentially corrupted) files that are
being modified to work with wxWidgets 2.9.1, in the default Unicode
build (They were last built and used w/ with 2.6x, IIRC.) I'm
currently at the stage of being able to display much if not all of the
GUI aspects, and execute at least several aspects of the processing.
However I'm getting the assert message below on exit. Any help w/
interpretation and approaches to diagnosis would be appreciated.
// Assert message
---------------------------
wxWidgets Debug Alert
---------------------------
..\..\src\common\object.cpp(354): assert "m_count > 0" failed in
wxRefCounter::DecRef(): invalid ref data count
Call stack:
[00] wxGUIAppTraitsBase::ShowAssertDialog
c:\wxwidgets-2.9.1\src\common\appcmn.cpp:502
[01] ShowAssertDialog
c:\wxwidgets-2.9.1\src\common\appbase.cpp:1253
[02] wxAppConsoleBase::OnAssertFailure
c:\wxwidgets-2.9.1\src\common\appbase.cpp:758
[03] wxDefaultAssertHandler
c:\wxwidgets-2.9.1\src\common\appbase.cpp:1053
[04] wxOnAssert
c:\wxwidgets-2.9.1\src\common\appbase.cpp:1129
[05] wxRefCounter::DecRef
c:\wxwidgets-2.9.1\src\common\object.cpp:354
[06] wxGridRowOrColAttrData::~wxGridRowOrColAttrData
c:\wxwidgets-2.9.1\src\generic\grid.cpp:733
[07] wxGridCellAttrProviderData::~wxGridCellAttrProviderData
[08] wxGridCellAttrProviderData::`scalar deleting destructor'
[09] wxGridCellAttrProvider::~wxGridCellAttrProvider
c:\wxwidgets-2.9.1\src\generic\grid.cpp:829
[10] wxGridCellAttrProvider::`scalar deleting destructor'
[11] wxGridTableBase::~wxGridTableBase
c:\wxwidgets-2.9.1\src\generic\grid.cpp:1004
[12] wxGridStringTable::~wxGridStringTable
[13] wxGridStringTable::`scalar deleting destructor'
[14] wxGrid::~wxGrid
c:\wxwidgets-2.9.1\src\generic\grid.cpp:1947
[15] wxGrid::`scalar deleting destructor'
[16] wxWindowBase::Destroy
c:\wxwidgets-2.9.1\src\common\wincmn.cpp:425
[17] wxWindowBase::DestroyChildren
c:\wxwidgets-2.9.1\src\common\wincmn.cpp:460
[18] wxWindow::~wxWindow
c:\wxwidgets-2.9.1\src\msw\window.cpp:579
[19] wxPanel::~wxPanel
c:\wxwidgets-2.9.1\src\generic\panelg.cpp:135
[20] wxPanel::`scalar deleting destructor'
// end of assert
As a separate, but potentially related, query, I've noticed the
following with wxString s. Hovering the cursor over such strings in a
VS environment has shown:
m_impl "some valid-looking srting content"
m_convertedToChar m_str=0x00000000 <Bad Ptr> m_len = 3459...
Should the bad pointer and length be of concern?
TIA,
Alec
--
Alec Ross
Queries wxCodex
that would/should have been deleted later by the normal sequence of
destructors. Look in the last instance of your code in the stack and
examine if you are doing any explicit deletions of class members that maybe
should be left alone.
HTH:
CodexQueries
> --
> Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
>
> To unsubscribe, send email to wx-users+u...@googlegroups.com
> or visit http://groups.google.com/group/wx-users
>
Vadim Zeitlin
AR> However I'm getting the assert message below on exit. Any help w/
AR> interpretation and approaches to diagnosis would be appreciated.
Something calls DecRef() too many times. If the problem is reproducible
you should be able to find the object that is being released and simply put
conditional breakpoints on DecRef() when "this == this-object-address" to
find where does it happen from.
AR> As a separate, but potentially related, query, I've noticed the
AR> following with wxString s. Hovering the cursor over such strings in a
AR> VS environment has shown:
AR> m_impl "some valid-looking srting content"
AR> m_convertedToChar m_str=0x00000000 <Bad Ptr> m_len = 3459...
AR>
AR> Should the bad pointer and length be of concern?
No, m_convertedToChar will be initialized when needed (i.e. when you call
mb_str()).
Regards,
VZ
--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/
Alec Ross
<que...@wxcodex.net> writes
>In past experience, this has been caused by explicitly deleting
>something that would/should have been deleted later by the normal
>sequence of destructors. Look in the last instance of your code in the
>stack and examine if you are doing any explicit deletions of class
>members that maybe should be left alone.
>
>HTH:
>
>CodexQueries
>
Thanks.
I have looked at the deletes; but I'll check this again.
Regards,
Alec
...
--
Alec Ross
Alec Ross
>
>AR> However I'm getting the assert message below on exit. Any help w/
>AR> interpretation and approaches to diagnosis would be appreciated.
>
> Something calls DecRef() too many times. If the problem is reproducible
>you should be able to find the object that is being released and simply put
>conditional breakpoints on DecRef() when "this == this-object-address" to
>find where does it happen from.
>
Sorry, I'm not sure exactly what you're suggesting here. Do you mean a
breakpoint in the library, in e.g. in a call to DecRef() in object.cpp,
or within the DecRef() code? I've never put a breakpoint into compiled
lib code before.
(Incidentally, the assert message suggested to me that it was a
wxGridRowOrColAttrData object that was being destroyed. And I think
this was occurring even when I did not expect a wxGrid to have been
constructed.)
...
>AR> m_convertedToChar m_str=0x00000000 <Bad Ptr> m_len = 3459...
>AR>
>AR> Should the bad pointer and length be of concern?
>
> No, m_convertedToChar will be initialized when needed (i.e. when you call
>mb_str()).
>
Thanks.
Regards,
Alec
--
Alec Ross
Vadim Zeitlin
AR> > Something calls DecRef() too many times. If the problem is reproducible
AR> >you should be able to find the object that is being released and simply put
AR> >conditional breakpoints on DecRef() when "this == this-object-address" to
AR> >find where does it happen from.
AR>
AR> Sorry, I'm not sure exactly what you're suggesting here. Do you mean a
AR> breakpoint in the library, in e.g. in a call to DecRef() in object.cpp,
AR> or within the DecRef() code?
Err, what's the difference? Anyhow, yes I did mean putting a (conditional)
break point on wxRefCounter::DecRef() in object.cpp.
AR> I've never put a breakpoint into compiled lib code before.
It's exactly the same as putting a breakpoint into compiled application
code...
AR> (Incidentally, the assert message suggested to me that it was a
AR> wxGridRowOrColAttrData object that was being destroyed. And I think
AR> this was occurring even when I did not expect a wxGrid to have been
AR> constructed.)
Actually if you destroy any ref counted objects at all this would explain
the bug too. But it shouldn't be possible to call delete on any of ref
counted objects.
Alec Ross
...
>AR>
>AR> Sorry, I'm not sure exactly what you're suggesting here. Do you mean a
>AR> breakpoint in the library, in e.g. in a call to DecRef() in object.cpp,
>AR> or within the DecRef() code?
>
> Err, what's the difference?
I didn't know if/how it would work.
,,,
Anyway, looking into this along the lines you've suggested, I think I've
established the wxGrid being destroyed at call [14] in the assert report
(copied below).
/// Assert report
/// end of assert report
Now I currently create three wxGrids in the app - and although I set
attributes for two of them, I don't for the one that seems to be
triggering the assert.
Looking into the DecRef() calls, with the DecRef() code listed below,
wxGridRowOrColAttrData::~wxGridRowOrColAttrData()
{
size_t count = m_attrs.GetCount();
for ( size_t n = 0; n < count; n++ )
{
m_attrs[n]->DecRef();
}
}
count == 18 m_nSize == 24
This iterates for n in 0, 1. Then crashes on the third iteration ( n ==
2 ).
I don't know the significance of the count and nSize variables. The
first grid that seems to be associated w/ the problem has two columns of
20 rows; but only 18 rows are completely displayed on the window. (I've
not tested it at sizes other than that when it is first created and
displayed.)
Any more helpful suggestions please?
Alec
--
Alec Ross
Vadim Zeitlin
AR> Now I currently create three wxGrids in the app - and although I set
AR> attributes for two of them, I don't for the one that seems to be
AR> triggering the assert.
This seems impossible. If you don't set any attributes for it, it
shouldn't have any.
AR> Looking into the DecRef() calls, with the DecRef() code listed below,
AR>
AR> wxGridRowOrColAttrData::~wxGridRowOrColAttrData()
AR> {
AR> size_t count = m_attrs.GetCount();
AR> for ( size_t n = 0; n < count; n++ )
AR> {
AR> m_attrs[n]->DecRef();
AR> }
AR> }
AR>
AR> count == 18 m_nSize == 24
AR>
AR> This iterates for n in 0, 1. Then crashes on the third iteration ( n ==
AR> 2 ).
So the third attribute must be the one that had been DecRef()'d before.
AR> I don't know the significance of the count and nSize variables.
m_nSize is internal, count is the number of attributes stored by this
object.
AR> Any more helpful suggestions please?
If you set a breakpoint on wxGridRowOrColAttrData::SetAttr() you should be
able to see where do you call this from.
Alec Ross
>AR> Now I currently create three wxGrids in the app - and although I set
>AR> attributes for two of them, I don't for the one that seems to be
>AR> triggering the assert.
>
> This seems impossible. If you don't set any attributes for it, it
>shouldn't have any.
>
I was wrong.
...
>
> So the third attribute must be the one that had been DecRef()'d before.
>
Thanks.
>
> If you set a breakpoint on wxGridRowOrColAttrData::SetAttr() you should be
>able to see where do you call this from.
>
Well I did set one; and found the debugging instructional but
time-consuming. Removing all my code to set attributes has cured the
problem. I'll re-add it incrementally to try to locate and cure the
problem.
Many thanks again,
Alec
--
Alec Ross