/bitcoin

Drop upgrade-cancel callback registration for a generic "cancelable" #10770

Open
wants to merge 2 commits into
from
+32 −34

Conversation

Reviewers

@sipa sipa

@ryanofsky ryanofsky

Assignees
No one assigned
Labels
GUI
Projects
None yet
Milestone
No milestone
6 participants
@TheBlueMatt @jonasschnelli @sipa @jj1010 @ryanofsky @fanquake
@TheBlueMatt
Contributor

TheBlueMatt commented Jul 7, 2017

Instead of passing a StartShutdown reference all the way up from
txdb, give ShowProgress a "cancelable" boolean, as StartShutdown
is pretty much always what you'll want to use to cancel. Use the
same boolean to allow cancel during initial block verification.

TheBlueMatt referenced this pull request Jul 7, 2017

Merged

Allow to cancel the txdb upgrade via splashscreen keypress 'q' #10660

src/qt/splashscreen.cpp
+ (cancel_possible ? (std::string("\n") + _("(press q to shutdown and continue later)"))
+ : std::string("")));
+
+ if (cancel_possible) {
@ryanofsky

ryanofsky Jul 7, 2017 • edited

Contributor

Don't you need to invoke setBreakAction(nullptr) here when cancel_possible is false?

Maybe better would be to get rid of this std::function madness and replace the SplashScreen::breakAction pointer with a simpler boolean std::atomic<bool> m_cancel_possible which you can just assign directly.

@TheBlueMatt

TheBlueMatt Jul 7, 2017

Contributor

Nice.

fanquake added the GUI label Jul 7, 2017

@jonasschnelli
Member

jonasschnelli commented Jul 9, 2017

Makes sense. I guess I over-engineered the flexible callback (I thought we should have a way to not only shutdown and have the future option to "continue" but this really makes little sense).

utACK 1d62f6e
src/qt/splashscreen.h
@@ -36,8 +36,8 @@ public Q_SLOTS:
/** Show message and progress */
void showMessage(const QString &message, int alignment, const QColor &color);
- /** Sets the break action */
- void setBreakAction(const std::function<void(void)> &action);
+ /** Sets if cancel is currently possible */
@ryanofsky

ryanofsky Jul 10, 2017

Contributor

I'd consider replacing "cancel possible" with "shutdown possible" everywhere in this PR. The function this is controlling is called StartShutdown. The display text is press q to shutdown. Why should this thing be named differently?

@TheBlueMatt

TheBlueMatt Jul 10, 2017

Contributor

"shutdown" is always possible (just may be slow), what you care about is cancelling the currnent "in progress" thing (and shutting down). I dont really care, but also dont think its particularly unclear?

@ryanofsky

ryanofsky Jul 10, 2017

Contributor

I dont really care, but also dont think its particularly unclear?

It's unclear to me what the flag is supposed to indicate or why it wouldn't always be true if shutdown is always possible. Maybe it should be called fast_shutdown_possible if that's what it actually means. Acked this because the PR is definitely a simplification, but I don't think the code or the reason for preventing the quit option from working after the upgrade is clear. I think better naming could help.

@TheBlueMatt

TheBlueMatt Jul 11, 2017

Contributor

Added some additional comments. I'm not really sure if thats a better name, though I agree cancel_possible is a bit strange.

@sipa
Owner

sipa commented Jul 11, 2017 • edited

This begs the question whether we shouldn't just have 'q for shutdown' always available? Maybe in some cases there is some initializationstep-specific cleanup, but there shouldn't be much as we're always allowed to crash anyway.
@TheBlueMatt
Contributor

TheBlueMatt commented Jul 11, 2017

@sipa yea, I thought about that. We should maybe move the boolean to just change the message to "will complete later if you shutdown now". I still think this is a nice cleanup, and given we're already in freeze for 0.15 it'd be too late to make that change for 0.15. If this sits for the next month without any movement I'll make that change for 16.
@sipa
Owner

sipa commented Jul 15, 2017

Tested. Segfaults when cancelling during upgrade:

Thread 4 "bitcoin-shutoff" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffe117d700 (LWP 6034)]
CCoinsViewCache::DynamicMemoryUsage (this=0x0) at coins.cpp:40
40	    return memusage::DynamicUsage(cacheCoins) + cachedCoinsUsage;
(gdb) bt
#0  CCoinsViewCache::DynamicMemoryUsage (this=0x0) at coins.cpp:40
#1  0x0000555555850c4e in FlushStateToDisk (chainparams=..., state=..., mode=mode@entry=FLUSH_STATE_ALWAYS, nManualPruneHeight=nManualPruneHeight@entry=0) at validation.cpp:1899
#2  0x00005555558521bc in FlushStateToDisk () at validation.cpp:1969
#3  0x00005555556f6bf5 in Shutdown () at init.cpp:219
#4  0x00005555555d0ed0 in BitcoinCore::shutdown (this=0x55555698e330) at qt/bitcoin.cpp:309
#5  0x00007ffff5962359 in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x00007ffff689835c in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#7  0x00007ffff689fb11 in QApplication::notify(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#8  0x00007ffff59358a0 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#9  0x00007ffff593802d in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x00007ffff5989b03 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x00007ffff1644377 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#12 0x00007ffff16445e0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x00007ffff164468c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x00007ffff5989f0f in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#15 0x00007ffff593388a in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x00007ffff5760fe3 in QThread::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x00007ffff5765c98 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x00007ffff504e6da in start_thread (arg=0x7fffe117d700) at pthread_create.c:456
#19 0x00007ffff387ed7f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:105
@TheBlueMatt
Contributor

TheBlueMatt commented Jul 15, 2017

@sipa hmm, I could be wrong but that strikes me as an issue that would also be present prior to the changes in this PR.
@TheBlueMatt
Contributor

TheBlueMatt commented Jul 16, 2017 • edited

@sipa yes, that appears to be another bug introduced in #10179 after d6af06d changed some semantics, I'll fix it in #10758 with my other pile of fixes that are gonna need to land for 15 anyway.

TheBlueMatt referenced this pull request Jul 16, 2017

Open

Fix some chainstate-init-order bugs. #10758

@jj1010

jj1010 commented Jul 16, 2017

src/qt/splashscreen.cpp
{
- breakAction = action;
-}
+ InitMessage(splash, title + strprintf("%d", nProgress) + "%" +
@sipa

sipa Jul 16, 2017

Owner

Please put a space or a newline between the title and the progress.

@TheBlueMatt

TheBlueMatt Jul 16, 2017

Contributor

OK, cleaned it up.

TheBlueMatt added some commits Jul 7, 2017

@TheBlueMatt TheBlueMatt Drop upgrade-cancel callback registration for a generic "cancelable" 
Instead of passing a StartShutdown reference all the way up from
txdb, give ShowProgress a "cancelable" boolean, as StartShutdown
is pretty much always what you'll want to use to cancel. Use the
same boolean to allow cancel during initial block verification.
 d4effec
@TheBlueMatt TheBlueMatt Clarify cancel_possible docs in a few places.
59147fa
@ryanofsky

ryanofsky reviewed Jul 25, 2017
View changes

utACK 59147fa. Only change since last review is rearranged progress string.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment