Bugfix: Initialize CWallet::nOrderPosNext on an empty wallet, and save it in db#1800
Conversation
There was a problem hiding this comment.
My head has difficulties parsing this English early in the morning.
Maybe something like "Returns the next sequential transaction order id" would be clearer? I think the increment is implicit in "next".
|
Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/da7b8c1260d91e3306eb18dd65633567cb31332f for binaries and test log. |
|
What is the severity of this bug? Does it prevent bitcoin from working at all when starting with an empty wallet? |
|
The position counter is uninitialized. So far I've never been able able to get it to a case where it happened to have any value other than zero, which is the correct and expected value for a new wallet. No matter what value it takes it should not be able to prevent bitcoin from working. The worst result would be some transactions appearing out of order. I found the issues while making a second code review of all the later pulls, I don't believe any problems have been reported related to this. |
|
In theory, a new wallet might put items out of order across restarts since they won't run the "process old data" function :/ |
|
bump, rc3? |
But fix properly, bitcoin upstream did not fix properly
5 participants
Thanks @gmaxwell for finding these bugs!