The subject line and my message from the previous
post is misleading; its not calling TreeView::setModel()
that crashes the program with enableUpdates() true
(in fact, I'm not sure if enableUpdates() is a factor yet),
its when _deleting_ an old model which was previously
set by the tree that _results_ in the program crashing.
For example:
// STARTBLOCK: CODE
WStandardItemModel* old = (WStandardItemModel*)tree_->model();
tree_->setModel(new WStandardItemModel(this));
delete old; // crash happens after this point
// ENDBLOCK
Then, valgrind gives an Invalid Read message before the program crashes:
// STARTBLOCK: VALGRIND REPORT EXCERPT
==15119== Thread 3:
==15119== Invalid read of size 8
==15119== at 0x52CCC3F: Wt::WModelIndex::parent() const (WModelIndex.C:38)
==15119== by 0x52CCCE7: Wt::WModelIndex::depth() const (WModelIndex.C:52)
==15119== by 0x52CCF84: Wt::WModelIndex::operator<(Wt::WModelIndex const&)
const (WModelIndex.C:86)
==15119== by 0x5346CE0: std::_Rb_tree<Wt::WModelIndex,
std::pair<Wt::WModelIndex const, Wt::WTreeViewNode*>,
std::_Select1st<std::pair<Wt::WModelIndex const, Wt::WTreeViewNode*> >,
std::less<Wt::WModelIndex>, std::allocator<std::pair<Wt::WModelIndex const,
Wt::WTreeViewNode*> > >::erase(Wt::WModelIndex const&) (stl_function.h:230)
==15119== by 0x532E886:
Wt::WTreeView::removeRenderedNode(Wt::WTreeViewNode*) (stl_map.h:538)
==15119== by 0x5330EFD: Wt::WTreeViewNode::~WTreeViewNode() (WTreeView.C:239)
==15119== by 0x53672DA: Wt::WWebWidget::~WWebWidget() (WWebWidget.C:193)
==15119== by 0x531BAF6: Wt::WTableCell::~WTableCell() (WTableCell:38)
==15119== by 0x53672DA: Wt::WWebWidget::~WWebWidget() (WWebWidget.C:193)
==15119== by 0x5330F05: Wt::WTreeViewNode::~WTreeViewNode() (WTreeView.C:240)
==15119== by 0x5272DAE: Wt::WContainerWidget::clear()
(WContainerWidget.C:215)
==15119== by 0x533A1FF: Wt::WTreeView::rerenderTree() (WTreeView.C:1852)
==15119== Address 0x95e7590 is 0 bytes inside a block of size 648 free'd
==15119== at 0x4C23EAD: operator delete(void*) (in
/usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
// ENDBLOCK
I have some trouble drawing conclusions from this report:
Is TreeView being used improperly in the code sample?
Why does TreeView have a dependence for the old
model during its rerendering behavior?
If the dependence is by design, is there a way to tell if
TreeView is through needing the old model?
If not by design, is this a bug?
As a note, I noticed that if I delete the tree first before I
delete the old model the program does not crash.
You can check out the test-case attachment from
my previous post to reproduce the crash if you wish
(I forgot to include the CMakeList file in it; bummer).
Regards.
------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest
