CWallet::ZapSelectTx removes transactions from the internal model, but leaves the UI in the dark.
Adding a NotifyTransactionChanged() should avoid having invalid transactions in the GUI.
Fixes #16950
CWallet::ZapSelectTx removes transactions from the internal model, but leaves the UI in the dark.
Adding a NotifyTransactionChanged() should avoid having invalid transactions in the GUI.
Fixes #16950
ACK addaf8af8268d918973883a304025d40af5a33c1 (tested both with and without this change)
Looks like the UI model is not updated if fQueueNotifications, which happens if anything is in progress:
https://github.com/bitcoin/bitcoin/blob/4c4ff4911a6dbf1555fb4cfc05092cb8fe2f9eba/src/qt/transactiontablemodel.cpp#L707-L722
Couldn't we trigger the crash in this case?
ACK addaf8af8268d918973883a304025d40af5a33c1 - tested that this fixes #16950
Couldn't we trigger the crash in this case?
Yes you can. Using this branch (addaf8af8268d918973883a304025d40af5a33c1), I triggered a rescan, called removeprunedfunds and tried opening the info dialog of the tx in the GUI:
* thread [#1](/bitcoin-bitcoin/1/), name = 'bitcoin-main', queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x18)
frame [#0](/bitcoin-bitcoin/0/): 0x00000001000bc638 bitcoin-qt`TransactionDesc::toHTML(interfaces::Node&, interfaces::Wallet&, TransactionRecord*, int) [inlined] std::__1::vector<CTxOut, std::__1::allocator<CTxOut> >::begin(this=0x0000000000000018 size=0) const at vector:1519:30 [opt]
1516 typename vector<_Tp, _Allocator>::const_iterator
1517 vector<_Tp, _Allocator>::begin() const _NOEXCEPT
1518 {
-> 1519 return __make_iter(this->__begin_);
1520 }
1521
1522 template <class _Tp, class _Allocator>
Target 0: (bitcoin-qt) stopped.
However, I'm not sure fixing that (less likely to hit, and likely more involved to fix) case has to block this PR.
Well maybe deletions shouldn't be queued?
Agree it's unlikely. Thoughts Jonas?
Perhaps removeprunedfunds should fail if a rescan is in progress (etc), but I think that can wait for a separate PR.
tACK addaf8a: tested with an unpruned wallet by calling removeprunedfunds on an RBF-replaced transaction. It neatly disappears from the UI.
Perhaps
removeprunedfundsshould fail if a rescan is in progress (etc), but I think that can wait for a separate PR.
Just to avoid the problem in the GUI? AFAIK there's no problem calling removeprunedfunds while rescanning in bitcoind.
Just in general so that concurrency is easier to reason about. But if it already works, don't fix it :-)
Milestone
0.19.0