Bug #7260
openWStandardItemModel::removeRows ajaxMode() assertion fail after upgrading to 3.4.1
0%
Description
After upgrading from Wt 3.3.12 to 3.4.1 we are starting to experience some problems when removing rows from a WStandardItemModel. I have tried to backtrace the error and seems to be an assertion fail in WTableView::spannerCount. It happens when trying to remove rows by calling:
model_removeRows(0, model_>rowCount());
The model can potentially have 0 row. The problem seems to be avoided if I explicitly check whether rowCount() is greater than 0.
I got the following backtrace:
site_man_web: /home/cpb/git/ros_build/build/wt/src/src/Wt/WTableView.C:359: int Wt::WTableView::spannerCount(Wt::Side) const: Assertion `ajaxMode()' failed.
Thread 9 "site_man_web" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffe0839700 (LWP 20258)]
0x00007ffff28f7428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007ffff28f7428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1 0x00007ffff28f902a in __GI_abort () at abort.c:89
#2 0x00007ffff28efbd7 in __assert_fail_base (fmt=,
assertion=assertion@entry=0x7ffff5f62a26 "ajaxMode()",
file=file@entry=0x7ffff5f61060 "/home/cpb/git/ros_build/build/wt/src/src/Wt/WTableView.C",
line=line@entry=359,
function=function@entry=0x7ffff5f6bce0 "int Wt::WTableView::spannerCount(Wt::Side) const")
at assert.c:92
#3 0x00007ffff28efc82 in GI_assert_fail (assertion=0x7ffff5f62a26 "ajaxMode()",
file=0x7ffff5f61060 "/home/cpb/git/ros_build/build/wt/src/src/Wt/WTableView.C", line=359,
function=0x7ffff5f6bce0 "int Wt::WTableView::spannerCount(Wt::Side) const") at assert.c:101
#4 0x00007ffff5a9720a in Wt::WTableView::spannerCount(Wt::Side) const ()
from /opt/wt-3.4.1/lib/libwt.so.3.4.1
#5 0x00007ffff5a9c1f2 in Wt::WTableView::modelRowsAboutToBeRemoved(Wt::WModelIndex const&, int, int) () from /opt/wt-3.4.1/lib/libwt.so.3.4.1
#6 0x00007ffff5aa364c in boost::detail::function::void_function_obj_invoker6<boost::_bi::bind_t<void, boost::_mfi::mf3<void, Wt::WTableView, Wt::WModelIndex const&, int, int>, boost::_bi::list4<boost::_bi::value<Wt::WTableView*>, boost::arg<1>, boost::arg<2>, boost::arg<3> > >, void, Wt::WModelIndex, int, int, Wt::NoClass, Wt::NoClass, Wt::NoClass>::invoke(boost::detail::function::function_buffer&, Wt::WModelIndex, int, int, Wt::NoClass, Wt::NoClass, Wt::NoClass) ()
from /opt/wt-3.4.1/lib/libwt.so.3.4.1
#7 0x00007ffff5802383 in boost::signals2::detail::signal6_impl<void, Wt::WModelIndex, int, int, Wt::NoClass, Wt::NoClass, Wt::NoClass, boost::signals2::optional_last_value, int, std::less, boost::function<void (Wt::WModelIndex, int, int, Wt::NoClass, Wt::NoClass, Wt::NoClass)>, boost::function<void (boost::signals2::connection const&, Wt::WModelIndex, int, int, Wt::NoClass, Wt::NoClass, Wt::NoClass)>, boost::signals2::mutex>::operator()(Wt::WModelIndex, int, int, Wt::NoClass, Wt::NoClass,---Type to continue, or q to quit---
Wt::NoClass) () from /opt/wt-3.4.1/lib/libwt.so.3.4.1
#8 0x00007ffff57fbfb3 in ?? () from /opt/wt-3.4.1/lib/libwt.so.3.4.1
#9 0x00007ffff57fc0a3 in Wt::WAbstractItemModel::beginRemoveRows(Wt::WModelIndex const&, int, int)
() from /opt/wt-3.4.1/lib/libwt.so.3.4.1
#10 0x00007ffff5a5e9fd in Wt::WStandardItemModel::beginRemoveRows(Wt::WModelIndex const&, int, int)
() from /opt/wt-3.4.1/lib/libwt.so.3.4.1
#11 0x00007ffff5a569aa in Wt::WStandardItem::removeRows(int, int) ()
from /opt/wt-3.4.1/lib/libwt.so.3.4.1
#12 0x00007ffff5a5e038 in Wt::WStandardItemModel::removeRows(int, int, Wt::WModelIndex const&) ()
from /opt/wt-3.4.1/lib/libwt.so.3.4.1
#13 0x00007ffff7b8766a in EventWidget::reloadModel (this=this@entry=0x7fffc40529b0,
reset=reset@entry=true) at /home/cpb/git/sw/siteman/src/db_web/src/event_widget.cpp:458
Files
Updated by Roel Standaert about 5 years ago
- Status changed from New to Feedback
It does look like it's possible that we get an assertion error when JavaScript support is disabled, and rows are removed from the model. That'll need to be fixed.
I do wonder why ajaxMode() is returning false in your case. Is JavaScript disabled or unavailable in the browser? Are you using progressive bootstrap?
Updated by Christopher Bilberg about 5 years ago
Yes, I also find it a bit odd. The same operation is done later, where it doesn't seem to be a problem.
Javascript is enabled and yes we are using progressive bootstrap.
Updated by Roel Standaert about 5 years ago
- Status changed from Feedback to Confirmed
Ah, I guess this is because of progressive bootstrap then. If you have a WTableView that's rendered on the first page load, it will first render it in a plain HTML version, because at that point, Wt can't tell that JavaScript support is available. Once Wt has detected JavaScript support, it will quickly be replaced with the JavaScript-enabled version.
Updated by Christopher Bilberg about 5 years ago
- File ajax_assert.tar.gz ajax_assert.tar.gz added
Yes, that seems to be the case. I was able to reproduce the problem with the attached code by enabling progressive-bootstrap. When disabled the issue doesn't seem to occur.
So the two options I have now is to either disable progressive-bootstrap or try to avoid rendering of the WTableView on the first page load?
Updated by Roel Standaert about 5 years ago
In the meantime, those workarounds should work, yes.