gui: SIGSEGV when starting v0.21.0rc3 #20776

Expected behavior

No SIGSEGV

Actual behavior

SIGSEGV:

Thread 1 "bitcoin-qt" received signal SIGSEGV, Segmentation fault.
0x0000555555609470 in GUIUtil::TableViewLastColumnResizingFixer::disconnectViewHeadersSignals (this=0x0) at qt/guiutil.cpp:479
479	    disconnect(tableView->horizontalHeader(), &QHeaderView::sectionResized, this, &TableViewLastColumnResizingFixer::on_sectionResized);
(gdb) where
[#0](/bitcoin-bitcoin/0/)  0x0000555555609470 in GUIUtil::TableViewLastColumnResizingFixer::disconnectViewHeadersSignals (this=0x0) at qt/guiutil.cpp:479
[#1](/bitcoin-bitcoin/1/)  0x0000555555609860 in GUIUtil::TableViewLastColumnResizingFixer::stretchColumnWidth (this=0x0, column=4) at qt/guiutil.cpp:538
[#2](/bitcoin-bitcoin/2/)  0x000055555578ce42 in TransactionView::resizeEvent (this=0x555559d7e4f0, event=0x7fffffffb490) at qt/transactionview.cpp:631
[#3](/bitcoin-bitcoin/3/)  0x00007ffff6fe7ebe in ?? ()
[#4](/bitcoin-bitcoin/4/)  0x0000000000000000 in ?? ()

To reproduce

Unknown. Haven't seen any crashes for over a year, but after building rc3 I got a crash on the first start. I'm running bitcoin-qt.

System information

Built from the v0.21.0rc3 tag on Debian with an SSD. Kernel 4.19.0-13-amd64. Debian GNU/Linux 10 (buster). XFCE4, xfwm4.

$ ldd qt/bitcoin-qt | grep -i qt
    libQt5Core.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 (0x00007f7fa9f00000)
    libQt5Gui.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5 (0x00007f7fa9975000)
    libQt5Widgets.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5 (0x00007f7fa931c000)
    libQt5Network.so.5 => /usr/lib/x86_64-linux-gnu/libQt5Network.so.5 (0x00007f7fa917b000)
    libQt5DBus.so.5 => /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5 (0x00007f7fa90e4000)

I ran it again and it worked fine the 2nd time.

Note to myself: Shouldn't be related to #14923 and #9683 because those are already fixed by #15203

I got what looks like the same crash a 2nd time. That's twice out of the 3 times that I've tried running rc3:

Thread 1 "bitcoin-qt" received signal SIGSEGV, Segmentation fault.
0x0000555555609470 in GUIUtil::TableViewLastColumnResizingFixer::disconnectViewHeadersSignals (this=0x0) at qt/guiutil.cpp:479
479	    disconnect(tableView->horizontalHeader(), &QHeaderView::sectionResized, this, &TableViewLastColumnResizingFixer::on_sectionResized);
(gdb) where
[#0](/bitcoin-bitcoin/0/)  0x0000555555609470 in GUIUtil::TableViewLastColumnResizingFixer::disconnectViewHeadersSignals (this=0x0) at qt/guiutil.cpp:479
[#1](/bitcoin-bitcoin/1/)  0x0000555555609860 in GUIUtil::TableViewLastColumnResizingFixer::stretchColumnWidth (this=0x0, column=4) at qt/guiutil.cpp:538
[#2](/bitcoin-bitcoin/2/)  0x000055555578ce42 in TransactionView::resizeEvent (this=0x5555575facc0, event=0x7fffffffb490) at qt/transactionview.cpp:631
[#3](/bitcoin-bitcoin/3/)  0x00007ffff6fe7ebe in ?? ()
[#4](/bitcoin-bitcoin/4/)  0x0000000000000000 in ?? ()

One thing I noticed this time is that the loading splash screen stayed up for a long time showing "Done loading". I have 13 different wallets listed in wallet=... lines in my bitcoin.conf (because this node is pruned, and I don't want any of my old wallets to need rescanning I keep them all loaded) and some are quite large - the largest 4 are each around 200MB of wallet.dat.

If it's "Done loading" then why does the splash screen stay up for another 4 minutes?

During the 4 to 5 minutes that the "Done loading" message is showing I see "New outbound peer connected" and blocks being fetched "UpdateTip" in the debug.log, but I'm unable to use the client for 4 or 5 minutes because all I see is the splash screen.

I checked multiple times during the 4 to 5 minute pause while 'Done loading' is displayed and every time I looked it was busy somewhere in here:

[#10](/bitcoin-bitcoin/10/) 0x0000555555e4e8b8 in CWalletTx::GetAvailableCredit (this=0x7fff5e6c07d0, fUseCache=true, filter=@0x7fffffffc040: 2 '\002') at wallet/wallet.cpp:1981
[#11](/bitcoin-bitcoin/11/) 0x0000555555e4f867 in CWallet::GetBalance (this=0x7fff6580b430, min_depth=0, avoid_reuse=true) at wallet/wallet.cpp:2139
[#12](/bitcoin-bitcoin/12/) 0x0000555555cf66b2 in interfaces::(anonymous namespace)::WalletImpl::getBalances (this=0x55555694f620) at interfaces/wallet.cpp:351
[#13](/bitcoin-bitcoin/13/) 0x0000555555cf686d in interfaces::(anonymous namespace)::WalletImpl::tryGetBalances (this=0x55555694f620, balances=..., block_hash=...) at interfaces/wallet.cpp:371
[#14](/bitcoin-bitcoin/14/) 0x00005555556b37f0 in WalletModel::pollBalanceChanged (this=0x5555591a4a30) at qt/walletmodel.cpp:99
[#15](/bitcoin-bitcoin/15/) 0x00005555556c9456 in QtPrivate::FunctorCall<QtPrivate::IndexesList<>, QtPrivate::List<>, void, void (WalletModel::*)()>::call(void (WalletModel::*)(), WalletModel*, void**) (f=(void (WalletModel::*)(WalletModel * const)) 0x5555556b36e0 <WalletModel::pollBalanceChanged()>, o=0x5555591a4a30, arg=0x7fffffffc4a0) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:134
[#16](/bitcoin-bitcoin/16/) 0x00005555556c6801 in QtPrivate::FunctionPointer<void (WalletModel::*)()>::call<QtPrivate::List<>, void>(void (WalletModel::*)(), WalletModel*, void**) (f=(void (WalletModel::*)(WalletModel * const)) 0x5555556b36e0 <WalletModel::pollBalanceChanged()>, o=0x5555591a4a30, arg=0x7fffffffc4a0) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:167
[#17](/bitcoin-bitcoin/17/) 0x00005555556c3277 in QtPrivate::QSlotObject<void (WalletModel::*)(), QtPrivate::List<>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) (which=1, this_=0x55555969f9e0, r=0x5555591a4a30, a=0x7fffffffc4a0, ret=0x0) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qobjectdefs_impl.h:396

Could this be an OOM?

I really don't think so. There's 32GB of RAM and another 32GB of swap on this machine. The swap is very rarely used.

Also, the crash always seems to be in TableViewLastColumnResizingFixer which makes me think it's something more deterministic than an OOM.

I've removed the 5 biggest wallets from my bitcoin.conf's "wallet=" list and haven't seen the crash since. It looks to me like it only happens when the client is taking a long time to start up.

If there are any particular things you want me to try I can add them back in and hopefully trigger the crash again.

Your SIGSEGV report shows that it is related to the TableViewLastColumnResizingFixer. There's currently an open PR #204 that aims to drop this class as it is buggy. Give that PR a go, I believe it may fix the issue.

@dooglus PR #204 has now been merged into master. Can you load in your large wallets and report back if this is still a problem for you?

Your SIGSEGV report shows that it is related to the TableViewLastColumnResizingFixer. There's currently an open PR #204 that aims to drop this class as it is buggy. Give that PR a go, I believe it may fix the issue.

@dooglus PR #204 has now been merged into master. Can you load in your large wallets and report back if this is still a problem for you?

I think this issue should be closed now.