Skip to content

Conversation

@laanwj
Copy link
Member

@laanwj laanwj commented Jul 13, 2017

Keep a flag in init.cpp indicating whether the data directory was locked.

If not, Interrupt and Shutdown are no-ops. This avoids things from being cleaned up if they were created by another instance.

I think this is the most robust, sure solution to #10815.

n.b.: We can't simple do "don't call Interrupt/Shutdown if Init*() failed" because some of the things needs to be interrupted and shut down in case of an error later in initialization when some things have already been started.

Keep a flag indicating whether the data directory was locked.

If not, Interrupt and Shutdown are no-ops. This avoids things from being
cleaned up if they were created by another instance.
@laanwj laanwj added the Bug label Jul 13, 2017
@laanwj laanwj added this to the 0.15.0 milestone Jul 13, 2017
@morcos
Copy link
Contributor

morcos commented Jul 13, 2017

This seems right to me and it solved the problem, but I'm not confident enough in understanding startup/shutdown to actually give it an ACK.

Thanks!

@meshcollider
Copy link
Contributor

utACK 73b6b4e

@jonasschnelli
Copy link
Contributor

utACK 73b6b4e

1 similar comment
@achow101
Copy link
Member

utACK 73b6b4e

@TheBlueMatt
Copy link
Contributor

TheBlueMatt commented Jul 14, 2017

Why not just make AppInitSanityCheck actually take the lock instead of just probing? It seems strange to call the entire shutdown sequence instead when literally none of it is needed when we already have a framework for skipping it (ala if AppinitSanityCheck fails, except for GUI, which really should be fixed in GUI, not by adding a boolean).

@sipa
Copy link
Member

sipa commented Jul 14, 2017

@TheBlueMatt I'm confused how that would help here.

@TheBlueMatt
Copy link
Contributor

My point is that this is (effecitlvely) not a problem in bitcoind. The issue in bitcoin-qt is that it calls Shutdown() where it should not (and bitcoind does not). If we want to separately fix the race that is also present in bitcoind, we should stop doing this strange LockDataDirectory(true)...one function return/call later...LockDataDirectory(false) thing.

std::unique_ptr<PeerLogicValidation> peerLogic;

/** Set at startup if the data directory was succesfully locked */
bool g_locked_data_directory = false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be static and atomic?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

static ok, atomic no, there's no concurrent modification as the flag is set from one place in the initialization sequence.

@laanwj
Copy link
Member Author

laanwj commented Jul 15, 2017

when we already have a framework for skipping it (ala if AppinitSanityCheck fails, except for GUI, which really should be fixed in GUI, not by adding a boolean).

The point, which I explain in #10815 (comment), is that that mechanism ALSO doesn't work for bitcoind.

If we want to separately fix the race that is also present in bitcoind, we should stop doing this strange LockDataDirectory(true)...one function return/call later...LockDataDirectory(false) thing.

The point of that 'strange sequence' is to be able to give a proper error in the case of -daemon.
If you take the data directory lock before forking, bad things happen. If you only take it after the fork, it's impossible to print an error to the standard output as that has been detached. That's why the probing is done.

Do you mean calling LockDataDirectory in a separate initialization step after daemonizing? That could work, though as it is already so easy to introduce bugs like this I thought it was more robust to add a flag.

@laanwj
Copy link
Member Author

laanwj commented Jul 15, 2017

Closign in favor of #10832

@laanwj laanwj closed this Jul 15, 2017
laanwj added a commit to laanwj/bitcoin that referenced this pull request Jul 17, 2017
Alternative to bitcoin#10818, alternative solution to bitcoin#10815.

After this change: All the AppInit steps before and inclusive
AppInitLockDataDirectory must not have Shutdown() called in case of
failure. Only when AppInitMain fails, Shutdown should be called.

Changes the GUI and bitcoind code to consistently do this.
laanwj added a commit that referenced this pull request Jul 17, 2017
…up core dump issue

dba485d init: Factor out AppInitLockDataDirectory (Wladimir J. van der Laan)

Pull request description:

  Alternative to #10818, alternative solution to #10815.

  After this change: All the AppInit steps before and inclusive AppInitLockDataDirectory must not have Shutdown() called in case of failure. Only when AppInitMain fails, Shutdown should be called.

  Changes the GUI and bitcoind code to consistently do this.

Tree-SHA512: 393e1a0ae05eb8e791025069e3ac4f6f3cdeb459ec63feda85d01cf6696ab3fed7632b6a0ac3641b8c7015af51d46756b5bba77f5e5f0c446f0c2dea58bbc92e
HashUnlimited pushed a commit to chaincoin/chaincoin that referenced this pull request Mar 9, 2018
Alternative to bitcoin#10818, alternative solution to bitcoin#10815.

After this change: All the AppInit steps before and inclusive
AppInitLockDataDirectory must not have Shutdown() called in case of
failure. Only when AppInitMain fails, Shutdown should be called.

Changes the GUI and bitcoind code to consistently do this.
PastaPastaPasta pushed a commit to PastaPastaPasta/dash that referenced this pull request Aug 2, 2019
…x startup core dump issue

dba485d init: Factor out AppInitLockDataDirectory (Wladimir J. van der Laan)

Pull request description:

  Alternative to bitcoin#10818, alternative solution to bitcoin#10815.

  After this change: All the AppInit steps before and inclusive AppInitLockDataDirectory must not have Shutdown() called in case of failure. Only when AppInitMain fails, Shutdown should be called.

  Changes the GUI and bitcoind code to consistently do this.

Tree-SHA512: 393e1a0ae05eb8e791025069e3ac4f6f3cdeb459ec63feda85d01cf6696ab3fed7632b6a0ac3641b8c7015af51d46756b5bba77f5e5f0c446f0c2dea58bbc92e
@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants