[bisq-network/bisq] Bisq sometimes fails to prompt user for password to unlock wallet (#4055)

Steven Barclay notifications at github.com
Fri Apr 3 09:16:11 UTC 2020

I recently had a look at this and was able to reproduce the issue on regtest by running an Alice instance over and over in a loop. I think the problem is a threading issue coming from the `bisq.core.btc.setup.WalletsSetup` class at the `UserThread::runAfter` method call. I added a couple of temporary log statements to the class as follows:

![Screenshot from 2020-04-03 14-36-23](https://user-images.githubusercontent.com/54855381/78338308-1e904580-75c5-11ea-9c3a-8f285a4b46b6.png)

Interestingly, adding the second log statement seemed to suppress the issue. At least, after starting the application 200 times it failed to show the password window only once, but on that occasion it failed to move past the splash screen at all (apparently because it failed to run the result handler passed to `UserThread::runAfter`).

After commenting out the second log statement and running Alice another 100 times, it got past the splash screen without showing the password window 5 times. Here is a screenshot of the relevant log output:

![Screenshot from 2020-04-03 12-48-56](https://user-images.githubusercontent.com/54855381/78339133-94e17780-75c6-11ea-904f-4d1a6b306c6d.png)

As can be seen (from extra temp logging I put in `bisq.core.app.WalletAppSetup`), it enters the result handler in the user thread _before_ it returns from the lambda passed into the previous `UserThread::execute` call (on a different thread) on line 254 in `WalletsSetup`.

I think the second log statement creates a happens-before relationship between the two updates to the internal JavaFX timeline made by the `execute` and `runAfter` calls, and without it the tasks can be scheduled out-of-order. As noted in the FIXME, `runAfter` is not meant to be run outside the user thread because it makes calls to non-thread-safe parts of the JavaFX API (almost all of it).

It should be fairly easy to fix the issue I think, e.g. by moving the `runAfter` call into the `execute` lambda. It might be worth searching for any other incorrect uses of `runAfter` in the codebase.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20200403/8089128c/attachment-0001.html>

More information about the bisq-github mailing list