Hi DiapDealer,
Yes it is the exact same bug. The problem is caused by QTabBar::setCurrentIndex() that makes a call to processEvents() before it has successfully set the current index!
I have no idea why it would do that but if enough QTabBar::removeTab calls are called fast enough the index never gets set properly resulting in segfaults in various places!
Code:
bt
* thread #1, name = 'CrBrowserMain', queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
* frame #0: 0x0000000108d1947a QtCore`QtSharedPointer::ExternalRefCountData::getAndRef(QObject const*) + 10
frame #1: 0x00000001000101df Sigil`TabManager::EmitTabChanged() + 111
frame #2: 0x0000000108e8fbec QtCore`QMetaObject::activate(QObject*, int, int, void**) + 3132
frame #3: 0x0000000100e7d83d QtWidgets`___lldb_unnamed_symbol2580$$QtWidgets + 701
frame #4: 0x0000000108e8fbec QtCore`QMetaObject::activate(QObject*, int, int, void**) + 3132
frame #5: 0x0000000100e5f736 QtWidgets`QTabBar::setCurrentIndex(int) + 406
frame #6: 0x0000000100e5fea1 QtWidgets`QTabBar::removeTab(int) + 1217
Here is a snippet of the backtrace showing the entire sequence of events.
I think we will need to disconnect the QTabBar::currentChanged signal before calling QTabBar::removeTab(int) and then manually invoking EmitTabChanged ourselves after the removeTab returns.
Otherwise we are just asking for trouble. The QTabBar::setCurentIndex is very broken in design by invoking processEvents before setting the actual new index.
KevinH
Quote:
Originally Posted by DiapDealer
The "quickly closing tabs" crash has been around for a while. I thought I mentioned it early in our port to QWebEngine. But I also seem to remember it was mitigated by some of our early bugfixing/trouble-shooting. I usually had to get pretty crazy about closing a bunch very quickly (with the mouse) to make it happen. I haven't tried hard to make it happen for a long time though.
|