Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Logger and initialization refinement and overhaul #17

Merged
merged 15 commits into from
Apr 18, 2015

Conversation

dexX7
Copy link
Member

@dexX7 dexX7 commented Apr 14, 2015

1) File logger and the loggers in general:

Usage:

  • Any entity that likes to use the logger has to include mastercore_log.h
  • To add a new category, an entry in mastercore_log.h and mastercore_log.cpp should be created
  • To enable or disable logging of a specific category, mastercore_log.cpp is the place to go

Notes:

  • It provides a central place for anything log related
  • With _log.h included, there is no need for external ... anymore
  • mp_log() and mp_error() were never used, so I don't see any need to carry them around for now
  • The categories might be enabled and disabled via RPC or config file at some point later

2) Console or status logger:

As subsitute for printf() another logger function PrintToConsole() was added:

  • PrintToConsole() has a similar behavior like file_log(), but instead of printing to mastercore.log, the logger prints directly to the console
  • PrintToConsole() is superior to printf(), as it comes with smarter tinyformat based formatting, and for example .c_str() can be omitted, when printing strings
  • The main motivation though, was to gain control over all those printf(), which were sort of annoying and difficult to tame.. ;)
  • In particular, encapsulating the console output allows to apply transformations, like using the option -logtimestamps to prepend the output with timestamps
  • It is thinkable to use categories in the future, or to add more configuration options, such as -quiet, to silence all regular console output

3) More useful and readable initializtion messages:

Instead of printing line numbers and file names, the status messages were updated.

Further, the dumping of balances after an initial scan was removed completely for a few reasons:

  • It was only printed after a scan, but not on every start
  • The information is not really relevant
  • The information is still available via other channels, e.g. via RPC mscrpc, getallbalances..MP

4) Progress reporting during the intial transaction scanning:

Every 30 seconds the progress of the scanning is printed to the console, written to the debug log file, and the RPC status, as well as the splash screen progress label, are updated.

It was important for me to show that Omni Core hasn't stalled, or is broken and doesn't do anything during the scanning, but in fact has already processed n of m blocks.

5) Shutdown request handling during the initial scanning:

Until now there was no way to shutdown Omni Core during the initial scanning, whether the shutdown request was intentionally, or triggered by some other event, for example a restart of the OS. The only way was to forcefully kill the process, which is neither user friendly, nor does it properly close the databases, and in the worst case it could result in some corruption.

Closing the QT splash screen window, or killing the process, triggers a global (Bitcoin Core based) shutdown request, which is honored by msc_initial_scan().

6) Low-hanging fruits on the way:

After @zathras-crypto gave green light for the initial merge, I started to wonder how to address any potential merge conflicts, and I finally came to the conclusion that it's probably better to bundle somewhat related changes, to reduce the impact on other pull requests.

While I generally think changes should come in smaller packets, the gain seemed to outweight the cost in this case, and in particular I'm referring to the last three commits 79749e9, f07a23d and 93eae99, which are hopefully easy to review and basically without any real impact.

7) No merge conflicts:

I actually got away with creating none for the pending pull requests.

The UI PR #5 can be merged directly, and #13 can be merged without conflicts, after merging zathras-crypto#63.

8) Let's see some results of the updated initialization and status reports... :)

$ ./src/test/test_bitcoin 
Initializing Omni Core v0.0.9.2-dev [unittest]
Loading trades database: OK
Loading send-to-owners database: OK
Loading transactions database: OK
Loading smart property database: OK
Exodus balance: 0.00000000 MSC
Omni Core initialization completed
Running 150 test cases...
Omni Core shutdown completed

*** No errors detected
$ ./src/qt/bitcoin-qt -logtimestamps # or bitcoind
2015-04-15 22:04:10 Initializing Omni Core v0.0.9.2-dev [main]
2015-04-15 22:04:10 Loading trades database: OK
2015-04-15 22:04:10 Loading send-to-owners database: OK
2015-04-15 22:04:10 Loading transactions database: OK
2015-04-15 22:04:10 Loading smart property database: OK
2015-04-15 22:04:10 Scanning for transactions in block 249498 to block 352066..
2015-04-15 22:04:25 Still scanning.. at block 253221 of 352066. Progress: 3.63 %
2015-04-15 22:04:40 Still scanning.. at block 256863 of 352066. Progress: 7.18 %
2015-04-15 22:04:55 Still scanning.. at block 258254 of 352066. Progress: 8.54 %
2015-04-15 22:05:10 Still scanning.. at block 259397 of 352066. Progress: 9.65 %
2015-04-15 22:05:25 Still scanning.. at block 260657 of 352066. Progress: 10.88 %
2015-04-15 22:05:40 Still scanning.. at block 261969 of 352066. Progress: 12.16 %
# ctrl+c, kill bitcoind, kill bitcoin-qt, or close bitcoin-qt
2015-04-15 22:05:44 Scan stopped early at block 262346 of block 352066
2015-04-15 22:05:44 3690943 transactions processed, 121 meta transactions found
2015-04-15 22:05:44 Exodus balance: 3845.77658936 MSC
2015-04-15 22:05:44 Omni Core initialization completed
2015-04-15 22:05:44 Omni Core shutdown completed
$ ./src/bitcoind -logtimestamps -startclean # or bitcoin-qt
2015-04-15 22:18:37 Initializing Omni Core v0.0.9.2-dev [regtest]
2015-04-15 22:18:37 Loading trades database: OK
2015-04-15 22:18:37 Loading send-to-owners database: OK
2015-04-15 22:18:37 Loading transactions database: OK
2015-04-15 22:18:37 Loading smart property database: OK
2015-04-15 22:18:37 Scanning for transactions in block 5 to block 749..
2015-04-15 22:18:43 1591 transactions processed, 432 meta transactions found
2015-04-15 22:18:43 Exodus balance: 38002.65700426 MSC
2015-04-15 22:18:43 Omni Core initialization completed

@dexX7 dexX7 force-pushed the oc-0.10-extract-logger branch from d25a48d to fad528d Compare April 14, 2015 15:49
@zathras-crypto
Copy link

Reviewed & supported. OK to merge from my end :)

dexX7 added 11 commits April 15, 2015 23:37
Usage:
- Any entity that likes to use the logger has to include `mastercore_log.h`
- To add a new category, an entry in `mastercore_log.h` and `mastercore_log.cpp` should be created
- To enable or disable logging of a specific category, `mastercore_log.cpp` is the place to go

Notes:
- It provides a central place for anything log related
- With `_log.h` included, there is no need for `external ...` anymore
- `mp_log()` and `mp_error()` were never used, so I don't see any need to carry them around for now
- The categories might be enabled and disabled via RPC or config file at some point later
Instead of printing line numbers and file names, the status messages were updated.

The dumping of all balances after the initial scan was removed completely for a few reasons:

- It was only printed after a scan, but not on every start
- The information may as well be outdated, if the scanning takes a long time (same applies to "Exodus balance", too..)
- The information is not really relevant
- The information is also available via other channels (e.g. via RPC "mscrpc", "getallbalances..MP")

Updated output:

```bash
$ ./src/qt/bitcoin-qt
Initializing Omni Core v0.0.9.2-dev [regtest]
Loading trades database: OK
Loading send-to-owners database: OK
Loading transactions database: OK
Loading smart property database: OK
Exodus balance: 37986.81207497 MSC
Omni Core initialization completed
Omni Core shutdown completed
```

```bash
$ ./src/qt/bitcoin-qt -startclean
Initializing Omni Core v0.0.9.2-dev [regtest]
Loading trades database: OK
Loading send-to-owners database: OK
Loading transactions database: OK
Loading smart property database: OK
Scanning for transactions in block 5 to block 749..
1591 transactions processed, 432 meta transactions found
Exodus balance: 37986.81207497 MSC
Omni Core initialization completed
Omni Core shutdown completed
```
No functional change (except `int -> unsigned int` as expected), and intended to make the changes of the following commits more visible.
In case the initial scan stopped early, it is reported. Further, prevent segfault, in case of some unexpected situation where `pblockindex == NULL`.
The initial transaction scanning can easily take several minutes, maybe longer, and the user should not have the impression the program froze.
Until now there was no way to stop the initial scan, but any shutdown request (intended or unintended) should be handled properly and shutdown the program within reasonable time, ideally without breaking anything.
`LogStatus()` is intended as superior replacement of `printf()`.

It allows formatting, doesn't require `.c_str()`, and could further be configured at some point. For example, there could be a `-quiet` configuration option, to prevent any regular output to the console.

In it's current form, it is affected by the configuration option `-logtimestamps`, to prepend timestamps to the console prints.
Ideally, `printf` is not used in the future, but completely substituted by `LogStatus()`, which allows further formatting, and doesn't require `.c_str()`.
The out of order block check is no longer done with Bitcoin Core 0.10, and the status reporting was a leftover.
`fDisableWallet` exists only, if not build with `--without-wallet`.

In the case Omni Core is indeed build with `--witout-wallet`, then `fDisableWallet` wouldn't exist at all, and the check would be faulty.
This was a rather low-hanging fruit, it has no functional impact and does not affect pending PRs.
@dexX7 dexX7 force-pushed the oc-0.10-extract-logger branch from fad528d to 93eae99 Compare April 15, 2015 22:22
@dexX7 dexX7 changed the title Move debug logger into seperated file Logger and initialization refinement and overhaul Apr 15, 2015
@dexX7
Copy link
Member Author

dexX7 commented Apr 15, 2015

Alright. This pull request was updated significantly.

Sorry @zathras-crypto, and please don't get scared by the wall of text, hehe.. the overall changes are actually rather small.

I figured it would probably make sense to bundle several related changes, to reduce the overall time, because otherwise I'd probably would have pushed the logger PR, then the follow up, then another follow up, and another follow up.

I suggest to step through commit to commit, and they were created to be easily reviewed one by one.

Please let me know, if there is anything that should changed, removed, added, ... and I'm curious, which work flow you would prefer for the future: smaller chucks or bundled pull requests like this?

Anyway, feedback is very welcomed.. :)

@zathras-crypto
Copy link

@dexX7 there are some excellent suggestions in here - starting to review now.

Quick nitpick - "LogStatus" instead of printf? It's just the name that seems off to me - to "log" something is to place an entry in a log; if we are not doing that (just printing to console does not log anything) is "log" the right term?

@dexX7
Copy link
Member Author

dexX7 commented Apr 16, 2015

Yeah, I have a mixed feeling about LogStatus(), too.

I'd be happy to replace this part, or the status messages, if you have any other idea.

Maybe StatusPrint(), ConsolePrint(), or just Print()?

@zathras-crypto
Copy link

Perhaps I'm 'old skool' hehe but I've always referred to it as 'echoing to console' (too much time spent on batch files in the 90s maybe?!?!? haha).

ConsolePrint(), PrintToConsole(), EchoToConsole() whatever you're comfortable with mate - I'm not that fussed, just thought that we might forget and assume LogStatus actually logs later down the track.

2 commits reviewed - so far so good - sitting in the waiting room at the doc's - if it wasn't for a lappy and tethering I think daytime TV (one big infomercial) would drive me nuts!!!

@dexX7
Copy link
Member Author

dexX7 commented Apr 16, 2015

In this case I tend to use PrintToConsole(), because I could imagine to rename file_log() to PrintToLog() at some point, which would match well.

@zathras-crypto
Copy link

In this case I tend to use PrintToConsole()

Agreed.

Ready for review

Reviewed, all fine with me mate - few minor niggles I've commented about but other than that OK with me. Great work mate, this is really good stuff :)

@dexX7
Copy link
Member Author

dexX7 commented Apr 16, 2015

Nice. So to summarize:

  • LogStatus() -> PrintToConsole()
  • Scan progress reporting time from 15 seconds to 30 seconds

What do you think about the messages?


Also a note about the logging altogther: we might adopt a similar approach like Bitcoin Core, where no categories are hardcoded, but provided as argument, for example:

LogPrint("selectcoins", "total %s\n", FormatMoney(nBest));

... instead of something like we use currently:

if (selectcoins) { LogPrintf("total %s\n", FormatMoney(nBest)); }

The categories are then activated via configuration or startup options:

./src/bitcoind -logtimestamps -debug=selectcoins -debug=bench -debug=net

@zathras-crypto
Copy link

So to summarize:
LogStatus() -> PrintToConsole()
Scan progress reporting time from 15 seconds to 30 seconds

Yep :)

What do you think about the messages?

Messages are clear - all good :)

Also a note about the logging altogther: we might adopt a similar approach like Bitcoin Core, where no categories are hardcoded, but provided as argument

Yeah this is a nice model - improving logging had been on my todo for a while so I really appreciate you cleaning it up. My main objection to our current model is the requirement to recompile to enable debug flags (which means we can't easily ask integrators/users to enable them for support purposes). I'd been planning to go RPC, but it makes sense to adopt the Bitcoin Core methodology and use startup params so there is a standard logging methodology right across the software.

@dexX7
Copy link
Member Author

dexX7 commented Apr 16, 2015

requirement to recompile ... planning to go RPC

The debug flags are no longer constant and could now be updated at runtime. :)

One more point: the Exodus balance is printed at the end of the initialization, but the intend wasn't really clear to me, so I'm unsure how to handle it, or if there might be another way.

I guess this is sort of a verification/consensus hint? If so, it might make sense to print to block height as well, to make it comparable.

@zathras-crypto
Copy link

I guess this is sort of a verification/consensus hint? If so, it might make sense to print to block height as well, to make it comparable.

Indeed. But it's irrelevant information for most. I think perhaps a better way to go would be to have an --informativestartup or similar option, and only echo stuff a developer would want if that param is set. What do you think?

EDIT: I guess --verbosestartup would be better wording if we did go in this direction.

@dexX7
Copy link
Member Author

dexX7 commented Apr 16, 2015

and only echo stuff a developer would want if that param is set

It's reasonable, but what would you consider as informative, in this context? Printing all balances brings us back to the beginning, and there is actually not much I could think of, which I would consider as helpful. Some general numbers maybe, like the number of transactions, properties, etc. maybe, but all this can also be retrieved via explicit commands.

@zathras-crypto
Copy link

It's interesting (for me at least) - I'm quite a visual person. The brain is essentially just one large pattern recognition engine and you'd be surprised at the things you spot simply because they look out of place compared to prior reference - even if you're not looking for them.

I figure when you start the client as many times as we do (numerous times per day) dumping some info would give us an easy spot on some things without directly looking for them - eg if we echo totaltrades and for whatever reason that number goes down, we'd likely pick up on the fact we'd broken MetaDEx without actually looking for it.

Perhaps that's just my perspective on things though - perhaps a bit 'fringe' hehe - tl:dr; if we had a --verbosestartup that printed extra info at startup I'd use it all the time for the above reason. As to what that extra info would contain I'm not sure - examples would be Exodus balance, number of transactions, number of trades, totaltokens for MSC (and perhaps a couple other high activity properties that aren't grant/revoke-able) so we would pick up if any transactions had incorrectly credited without debiting or vice-versa.

All just thinking out loud here mate :)

@dexX7
Copy link
Member Author

dexX7 commented Apr 16, 2015

Don't get me wrong, I like the idea, and a clean summary would be awesome. I have just some trouble pinning down specifics, at least when I think about it at the moment.

It's easier for me to see something, and use that as basis, so to speak. :) But when I further think about it: I'd be interested in protocol usage information, e.g. the number (in total and "recently") of properties created, transactions or trades. Also important in my opinion would be to know, whether the client is fully synchronized and up to date, given that "initialized" doesn't equal "up to date", but only "started".

@zathras-crypto
Copy link

Re my comments on splash above, I tested it - works well - this is a very nice change here mate thanks :)

I just dropped the following into msc_initial_scan (adapted from your PR as a quick test) - seems to work well :)

if (GetTime() >= nNow + 15) {
    double dProgress = 100.0 * (blockNum - nHeight) / (max_block - nHeight);
    std::string updateText = strprintf("Still scanning.. at block %d of %d. Progress: %.2f %%\n", blockNum, max_block, dProgress);
    uiInterface.InitMessage(_(updateText.c_str()));
    nNow = GetTime();
}

image

@dexX7
Copy link
Member Author

dexX7 commented Apr 16, 2015

Ha! Nicely done. I was actually thinking about the progress signal, but this seems to be easier than anticipated.

I'll finish the branch quickly, and merge, to get a basis for the UI integration. :)

Quick side note re: _(updateText.c_str()):

/**
 * Translation function: Call Translate signal on UI interface, which returns a boost::optional result.
 * If no translation slot is registered, nothing is returned, and simply return the input.
 */
inline std::string _(const char* psz)
{
    boost::optional<std::string> rv = uiInterface.Translate(psz);
    return rv ? (*rv) : psz;
}

In this case there would be no sentence or word to translate, but a bunch of words with numbers, which are probably difficult to translate. :)

dexX7 added 3 commits April 17, 2015 03:52
The internally used functions were also renamed:

- DebugLogPrint to LogFilePrint
- StatusLogPrint to ConsolePrint

The loggers are now available via:

- file_log (unchanged)
- PrintToConsole (as discussed)
- Increase time between progress reports from 15 s to 30 s
- Stop early, if a block could not be retrieved from the disk
- Extract progress reporting (to be ready to fire some signals or whatsoever)
@dexX7
Copy link
Member Author

dexX7 commented Apr 17, 2015

Updated as discussed. Diff: 93eae99...dexX7:oc-0.10-extract-logger

@zathras-crypto
Copy link

Did you want to throw a UI splash update in there too mate?

static void ReportScanProgress(int nFirst, int nCurrent, int nLast)
{
    double dProgress = 100.0 * (nCurrent - nFirst) / (nLast - nFirst);
    std::string progressText = strprintf("Still scanning.. at block %d of %d. Progress: %.2f %%\n", nCurrent, nLast, dProgress);
    PrintToConsole(progressText);
    uiInterface.InitMessage(progressText.c_str());
}

@dexX7
Copy link
Member Author

dexX7 commented Apr 17, 2015

@zathras-crypto: what are the up or downsides over uiInterface.ShowProgress(title, nProgress?

I'll give it a try: as far as I can see:


When using bitcoind, InitMessage() writes to debug.log:

2015-04-17 14:49:36 No coin database inconsistencies in last 7 blocks (74 transactions)
2015-04-17 14:49:36  block index            1865ms
2015-04-17 14:49:36 init message: Parsing Omni Layer transactions...
2015-04-17 14:49:41 init message: Still scanning.. at block 273003 of 349450. Progress: 11.57 %
2015-04-17 14:49:46 init message: Still scanning.. at block 288789 of 349450. Progress: 29.83 %

When using bitcoind, InitMessage() updates the RPC response:

$ ./src/bitcoin-cli getinfo -wait
error: {"code":-28,"message":"Parsing Omni Layer transactions..."}
$ ./src/bitcoin-cli getinfo -wait
error: {"code":-28,"message":"Still scanning.. at block 273003 of 349450. Progress: 11.57 %"}
$ ./src/bitcoin-cli getinfo -wait
error: {"code":-28,"message":"Still scanning.. at block 288789 of 349450. Progress: 29.83 %"}

When using bitcoin-qt, InitMessage() also updates the message on the splash screen:

pei9lvr


When using bitcoind, ShowProgress() does not write to debug.log.

When using bitcoind, ShowProgress() does not update the RPC response.

When using bitcoin-qt, ShowProgress() updates the message on the splash screen:

jmjdcl2


When mixing this with our PrintToConsole()...

debug.log splash rpc console
bitcoind, InitMessage x - x -
bitcoind, ShowProgress - - - -
bitcoind, InitMessage, PrintToConsole x - x x
bitcoind, ShowProgress, PrintToConsole - - - x
bitcoin-qt, InitMessage x x x -
bitcoin-qt, ShowProgress - x - -
bitcoin-qt, InitMessage, PrintToConsole x x x x
bitcoin-qt, ShowProgress, PrintToConsole - x - x

I'd like:

    1. frequent updates of the splash screen
    1. frequent updates of the RPC status response
    1. infrequent, or no output to the debug.log
    1. infrequent output to the console, ideally only if not in UI mode

So far, I'd say combining InitMessage() with PrintToConsole() would be the way to go, with a time of 30 seconds.

I tested additionally firing ShowProgress() more often, but this just didn't seem clean, even though it may create an odd impression, if the UI just pauses for 30 seconds, and then jumps a few percent.

- Prints to console
- Writes to debug.log
- Updates RPC status message
- Updates splash screen label, when using Omni Core QT
@zathras-crypto
Copy link

@zathras-crypto: what are the up or downsides

I favour InitMessage() due to the RPC updates (though I had not realized it pumped into debug.log too - I spend all my time looking at mastercore.log I guess I should pop over to the bitcoin logs every now and then!!!)

Logging these "still scanning..." lines seems excessive, but updating the RPC response during startup is very beneficial and it sounds like from your testing it's both or neither.

@zathras-crypto
Copy link

  1. Shutdown request handling during the initial scanning

Figured I'd just drop a note here - I'm still looking into it, but I've added your fix in msc_initial_scan() as per the following:

if (ShutdownRequested()) {
        file_log("Shutdown requested, stop scan at block %d of %d\n", blockNum, max_block);
        break;
    }

But am still getting a "fatal internal error" when I call a shutdown during scan - output:

Auditor was notified of a new property creation with ID 2147483676
Auditor was notified of an increase of 500 tokens for property 2147483676 due to Fixed issuance (txid: 972ca2b99a62475313212db4083bfa6ff5150c47b74db9572fd1e875d0aeefa6)
Auditor was notified of a new property creation with ID 2147483677
Auditor was notified of an increase of 500000000000000 tokens for property 2147483677 due to Fixed issuance (txid: 46e8b47764cc13309ec7b19cee6e39932c7f44a7d2cd82a9d2a9ba5eadd0c539)
Auditor has detected an invalid trade (txid: 75b687ca67f580d2ab1f7b88afc30fb1893d6eae4d40e83e6a596e49d21801a5) present in the MetaDEx following block 307607
Error: Error: A fatal internal error occured, see debug.log for details

2MuiZNuQR2vEmCq81XRTGRSHNETUGxEWR3C =>            +0.00000000 [SO_RESERVE=            +0.00000000 , ACCEPT_RESERVE=            +0.00000000 ]            +0.00000000
2Mw1R9LibSx7bLvrrXqDFj6dVFDnEdLuQsV =>          +151.53431577 [SO_RESERVE=            +0.00000000 , ACCEPT_RESERVE=            +0.00000000 ]            +0.00000000
<<<<<blah blah cut>>>>>
n4ckUx8KQP7QMtpDT9adpVf7RFZw8J2VRy =>            +2.22334400 [SO_RESERVE=            +0.00000000 , ACCEPT_RESERVE=            +0.00000000 ]            +0.00000000
n4gWyudHNTKwfXcwcmUhUJ87LYxfGk9dvx =>            +2.00000000 [SO_RESERVE=            +0.00000000 , ACCEPT_RESERVE=            +0.00000000 ]            +0.00000000
starting block= 263000, max_block= 349410
n_total= 947365, n_found= 637
[Initialized] Exodus balance: 27841.05142034
mastercore_shutdown(), line 2659, file: mastercore.cpp

I'm using if (!GetBoolArg("-overrideforcedshutdown", false)) AbortNode("Shutting down due to audit failure"); as the requester.

As I say just FYI, I'll have a nose around & see what I can find :)

EDIT: tail of debug.log here but not much help

2015-04-17 22:55:27 init message: Verifying blocks...
2015-04-17 22:55:27 Verifying last 1 blocks at level 3
2015-04-17 22:55:27 No coin database inconsistencies in last 2 blocks (67 transactions)
2015-04-17 22:55:27  block index            4338ms
2015-04-17 22:55:27 init message: Performing out of order block detection...
2015-04-17 22:55:27 init message: Parsing Omni Layer transactions...
2015-04-17 22:56:50 *** Shutting down due to audit failure
2015-04-17 22:56:50 Error: Error: A fatal internal error occured, see debug.log for details
2015-04-17 22:56:50 init message: Loading wallet...
2015-04-17 22:56:50 nFileVersion = 100100
2015-04-17 22:56:50 Keys: 0 plaintext, 213 encrypted, 213 w/ metadata, 213 total
2015-04-17 22:56:50  wallet                   16ms
2015-04-17 22:56:50 mapBlockIndex.size() = 349530
2015-04-17 22:56:50 nBestHeight = 349410
2015-04-17 22:56:50 setKeyPool.size() = 100
2015-04-17 22:56:50 mapWallet.size() = 167
2015-04-17 22:56:50 mapAddressBook.size() = 11
2015-04-17 22:56:50 init message: Loading addresses...
2015-04-17 22:56:50 Loaded 8529 addresses from peers.dat  36ms
2015-04-17 22:56:50 init message: Done loading
2015-04-17 22:56:50 net thread start
2015-04-17 22:56:50 dumpaddr thread start
2015-04-17 22:56:50 addcon thread start
2015-04-17 22:56:50 opencon thread start
2015-04-17 22:56:50 msghand thread start
2015-04-17 22:56:50 dnsseed thread start
2015-04-17 22:56:50 dumpaddr thread stop
2015-04-17 22:56:50 opencon thread interrupt
2015-04-17 22:56:50 msghand thread interrupt
2015-04-17 22:56:50 dnsseed thread interrupt
2015-04-17 22:56:50 addcon thread interrupt
2015-04-17 22:56:50 net thread interrupt
2015-04-17 22:56:50 ERROR: AcceptToMemoryPool : inputs already spent
2015-04-17 22:56:50 ERROR: AcceptToMemoryPool : inputs already spent
2015-04-17 22:56:51 ERROR: AcceptToMemoryPool : inputs already spent
2015-04-17 22:56:51 Shutdown: In progress...
2015-04-17 22:56:51 StopNode()
2015-04-17 22:56:51 Shutdown: done

@dexX7
Copy link
Member Author

dexX7 commented Apr 17, 2015

Logging these "still scanning..." lines seems excessive

Given that this progress blocks the whole program, frequent updates aren't that bad, especially when almost every second something is written to the debug.log. FWIW: users scan a whole lot of transactions usually only once.

I don't really like it either though, and I also don't like the infrequent UI updates, but I think it's a middleground, and the alternative, a smarter status reporter, with different time settings and more targeted reporting, seems like an overkill - at least at the very moment.

This could be something for a follow up, and it sort of fits into the category of more targeted signaling in general.

But am still getting a "fatal internal error" when I call a shutdown during scan - output

Let me quickly build and test your branch. Can you describe how I can reproduce the issue?

@zathras-crypto
Copy link

but I think it's a middleground

Agreed - it's a fantastic improvement over what we had previously (an apparent hung process for 60 mins) :)

Can you describe how I can reproduce the issue?

If you just build and run 0.0.10-Z-Auditor the auditor is enabled by default - you can play with the omni_debug_auditor and omni_debug_auditor_verbose settings in omnicore_auditor.cpp but I don't think you'll need to, you should just see it attempt to shutdown and fail when it detects that bad trade in the MetaDEx on testnet.

Oh, and run with --startclean so it reparses everything to pick up the issue :)

Thanks again bud

@zathras-crypto
Copy link

Note, if you want to play around with it just introduce a math error somewhere (for example in STO calculation or something) that results in tokens disappearing/appearing unexpectedly to see it in action :)

@dexX7
Copy link
Member Author

dexX7 commented Apr 17, 2015

But am still getting a "fatal internal error" when I call a shutdown during scan

Haha oh well. This was unexpected.. :) Check this out: src/main.cpp#L2838

@zathras-crypto
Copy link

Haha oh well. This was unexpected.. :) Check this out: src/main.cpp#L2838

Oh! That wasn't there in 0.9 - hmm - that will affect shutdown's due to alerts also - nice spot :)

@dexX7
Copy link
Member Author

dexX7 commented Apr 18, 2015

Yeah. :)

Is there anything you'd like to change in this PR before a merge?

@zathras-crypto
Copy link

Nope, it all looks good mate
On Apr 18, 2015 10:03 AM, "dexX7" [email protected] wrote:

Yeah. :)

Is there anything you'd like to change in this PR before a merge?


Reply to this email directly or view it on GitHub
#17 (comment).

@dexX7 dexX7 merged commit 3f89cd0 into OmniLayer:omnicore-0.0.10 Apr 18, 2015
dexX7 added a commit that referenced this pull request Apr 18, 2015
3f89cd0 Report initial scanning progress via multiple channels (dexX7)
355bf3d Update, refine and document msc_initial_scan (dexX7)
fe25326 Document mastercore_init and mastercore_shutdown (dexX7)
4339037 Rename LogStatus to PrintToConsole (and related) (dexX7)
93eae99 Superficial cleanup of unused parts and comments (dexX7)
f07a23d Guard against build without wallet during initialization (dexX7)
79749e9 Remove obsolete block order check status message (dexX7)
8fb73fc Replace most printf with LogStatus() (dexX7)
6a8a0cc Add LogStatus() to print directly to the console (dexX7)
947e52f Handle shutdown request during initial scan (dexX7)
3d4e079 Print initial scanning status every 15 seconds (dexX7)
0c80d4f Handle early or unfinished stop of initial transaction scan (dexX7)
8e1e138 Prepare and format msc_initial_scan() (dexX7)
6e9ae6e Prettify printing of initialization status messages (dexX7)
701ca0a Move debug logger into seperated file (dexX7)
@dexX7
Copy link
Member Author

dexX7 commented Apr 18, 2015

Awesome.

Here is a tip for your current branches (except the class C branch, which unfortunally requires a lot, but no different than the following, manual tweaking):

# update the local copy of the main branch
git fetch upstream omnicore-0.0.10
git checkout omnicore-0.0.10
git pull upstream omnicore-0.0.10

# then checkout your feature branch
git checkout 0.0.10-Z-UI

# and apply all commits upon the new "base"
git rebase omnicore-0.0.10

This should work without any issue for the UI branch, and I prefer this route over merging some main branch into a feature branch, every time there is an update, but maybe that's just personal taste. :)


When doing this with the auditor branch, at some point git will complain due to conflicts in mastercore.cpp:

Auto-merging src/mastercore_tx.cpp
Applying: Auditor : omnicore_auditor.cpp/h
Applying: Auditor : makefile changes
Applying: Auditor : remove manual debug line
Applying: Auditor : block sequence check
Applying: Auditor : Add MetaDEx bad trades check
Applying: Auditor : include DexX's fix for breaking out of scan (note still fatal error on shutdown)
Using index info to reconstruct a base tree...
M   src/mastercore.cpp
Falling back to patching base and 3-way merge...
Auto-merging src/mastercore.cpp
CONFLICT (content): Merge conflict in src/mastercore.cpp
Failed to merge in the changes.
Patch failed at 0008 Auditor : include DexX's fix for breaking out of scan (note still fatal error on shutdown)
The copy of the patch that failed is found in:
   ~/Projects/Cpp/omnicore/.git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

Here, you could manually resolve the conflict by removing the red lines:

@@ -1575,10 +1575,23 @@ static int msc_initial_scan(int nFirstBlock)
             break;
         }

-<<<<<<< HEAD
         if (GetTime() >= nNow + 30) { // seconds
             ReportScanProgress(nFirstBlock, nBlock, nLastBlock);
             nNow = GetTime();
         }
-=======
-  CBlock block;
-  for (int blockNum = nHeight;blockNum<=max_block;blockNum++)
-  {
-    if (ShutdownRequested()) {
-        file_log("Shutdown requested, stop scan at block %d of %d\n", blockNum, max_block);
-        break;
-    }
-
-    CBlockIndex* pblockindex = chainActive[blockNum];
-    string strBlockHash = pblockindex->GetBlockHash().GetHex();
->>>>>>> Auditor : include DexX's fix for breaking out of scan (note still fatal error on shutdown)

         CBlockIndex* pblockindex = chainActive[nBlock];
         if (NULL == pblockindex) break;

And after mastercore.cpp was saved, the file can be tagged as updated, and it can continue:

git add src/mastercore.cpp
git rebase --continue

Next, git will complain, because this specific commit is now empty, and this can be resolved by:

git rebase --skip

... and you're done! :)

This is probably followed by overwriting the remote version of that branch:

git push origin 0.0.10-Z-Auditor -f

See here - it shows "commited by dexx", because I'm not you obviously.. :)

@zathras-crypto
Copy link

Hmm, I actually just did this before seeing your comment - I just needed to pull from origin, resolve that merge conflict in mastercore.cpp then just use git add/git commit followed by a push - I didn't need to do the rebase stuff (zathras-crypto@6c7d919) - did I miss something?

@dexX7
Copy link
Member Author

dexX7 commented Apr 18, 2015

... did I miss something?

Haha no.. rebasing is just an alternative to merging, but it's perfectly fine. :)

But unfortunally I noticed one of the later commits of this PR actually did cause a conflict for the class C branch.. :/ (~two lines change though)

@zathras-crypto
Copy link

But unfortunally I noticed one of the later commits of this PR actually did cause a conflict for the class C branch.. :/ (~two lines change though)

Two lines ❗

No problems at all mate, it's to be expected when we're bouncing around various different things :)

@dexX7
Copy link
Member Author

dexX7 commented Apr 18, 2015

Two lines

Maybe I'm overly concerned, when it comes to those things, but let's just say:

I'm trying to avoid to interrupt the workflow of other pull requests, which have a higher priority in my opinion.. at least as best as I can. :)

@dexX7 dexX7 modified the milestone: 0.0.10.0 Dec 30, 2015
bvbfan pushed a commit to bvbfan/omnicore that referenced this pull request Jun 6, 2023
fac04cb refactor: Add lock annotations to Active* methods (MacroFake)
fac15ff Fix logical race in rest_getutxos (MacroFake)
fa97a52 Fix UB/data-race in RPCNotifyBlockChange (MacroFake)
fa530bc Add ChainstateManager::GetMutex(), an alias for ::cs_main (MacroFake)

Pull request description:

  This fixes two issues:

  * A data race in `ActiveChain`, which returns a reference to the chain (a `std::vector`), which is not thread safe. See also below traceback.
  * A corrupt rest response, which returns a blockheight and blockhash, which are unrelated to each other and to the result, as the chain might advance between each call without cs_main held.

  The issues are fixed by taking cs_main and holding it for the required time.

  ```
  ==================
  WARNING: ThreadSanitizer: data race (pid=32335)
    Write of size 8 at 0x7b3c000008f0 by thread T22 (mutexes: write M131626, write M151, write M131553):
      #0 std::__1::enable_if<(is_move_constructible<CBlockIndex**>::value) && (is_move_assignable<CBlockIndex**>::value), void>::type std::__1::swap<CBlockIndex**>(CBlockIndex**&, CBlockIndex**&) /usr/lib/llvm-13/bin/../include/c++/v1/__utility/swap.h:39:7 (bitcoind+0x501239)
      OmniLayer#1 std::__1::vector<CBlockIndex*, std::__1::allocator<CBlockIndex*> >::__swap_out_circular_buffer(std::__1::__split_buffer<CBlockIndex*, std::__1::allocator<CBlockIndex*>&>&) /usr/lib/llvm-13/bin/../include/c++/v1/vector:977:5 (bitcoind+0x501239)
      OmniLayer#2 std::__1::vector<CBlockIndex*, std::__1::allocator<CBlockIndex*> >::__append(unsigned long) /usr/lib/llvm-13/bin/../include/c++/v1/vector:1117:9 (bitcoind+0x501239)
      OmniLayer#3 std::__1::vector<CBlockIndex*, std::__1::allocator<CBlockIndex*> >::resize(unsigned long) /usr/lib/llvm-13/bin/../include/c++/v1/vector:2046:15 (bitcoind+0x4ffe29)
      OmniLayer#4 CChain::SetTip(CBlockIndex*) src/chain.cpp:19:12 (bitcoind+0x4ffe29)
      OmniLayer#5 CChainState::ConnectTip(BlockValidationState&, CBlockIndex*, std::__1::shared_ptr<CBlock const> const&, ConnectTrace&, DisconnectedBlockTransactions&) src/validation.cpp:2748:13 (bitcoind+0x475d00)
      OmniLayer#6 CChainState::ActivateBestChainStep(BlockValidationState&, CBlockIndex*, std::__1::shared_ptr<CBlock const> const&, bool&, ConnectTrace&) src/validation.cpp:2884:18 (bitcoind+0x47739e)
      OmniLayer#7 CChainState::ActivateBestChain(BlockValidationState&, std::__1::shared_ptr<CBlock const>) src/validation.cpp:3011:22 (bitcoind+0x477baf)
      OmniLayer#8 node::ThreadImport(ChainstateManager&, std::__1::vector<fs::path, std::__1::allocator<fs::path> >, ArgsManager const&) src/node/blockstorage.cpp:883:30 (bitcoind+0x23cd74)
      OmniLayer#9 AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7::operator()() const src/init.cpp:1657:9 (bitcoind+0x15863e)
      OmniLayer#10 decltype(static_cast<AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7&>(fp)()) std::__1::__invoke<AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7&>(AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7&) /usr/lib/llvm-13/bin/../include/c++/v1/type_traits:3918:1 (bitcoind+0x15863e)
      OmniLayer#11 void std::__1::__invoke_void_return_wrapper<void, true>::__call<AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7&>(AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7&) /usr/lib/llvm-13/bin/../include/c++/v1/__functional/invoke.h:61:9 (bitcoind+0x15863e)
      OmniLayer#12 std::__1::__function::__alloc_func<AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7, std::__1::allocator<AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7>, void ()>::operator()() /usr/lib/llvm-13/bin/../include/c++/v1/__functional/function.h:171:16 (bitcoind+0x15863e)
      OmniLayer#13 std::__1::__function::__func<AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7, std::__1::allocator<AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7>, void ()>::operator()() /usr/lib/llvm-13/bin/../include/c++/v1/__functional/function.h:345:12 (bitcoind+0x15863e)
      OmniLayer#14 std::__1::__function::__value_func<void ()>::operator()() const /usr/lib/llvm-13/bin/../include/c++/v1/__functional/function.h:498:16 (bitcoind+0x88891f)
      OmniLayer#15 std::__1::function<void ()>::operator()() const /usr/lib/llvm-13/bin/../include/c++/v1/__functional/function.h:1175:12 (bitcoind+0x88891f)
      OmniLayer#16 util::TraceThread(char const*, std::__1::function<void ()>) src/util/thread.cpp:18:9 (bitcoind+0x88891f)
      OmniLayer#17 decltype(static_cast<void (*>(fp)(static_cast<char const*>(fp0), static_cast<AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7>(fp0))) std::__1::__invoke<void (*)(char const*, std::__1::function<void ()>), char const*, AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7>(void (*&&)(char const*, std::__1::function<void ()>), char const*&&, AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7&&) /usr/lib/llvm-13/bin/../include/c++/v1/type_traits:3918:1 (bitcoind+0x157e6a)
      OmniLayer#18 void std::__1::__thread_execute<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (*)(char const*, std::__1::function<void ()>), char const*, AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7, 2ul, 3ul>(std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (*)(char const*, std::__1::function<void ()>), char const*, AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7>&, std::__1::__tuple_indices<2ul, 3ul>) /usr/lib/llvm-13/bin/../include/c++/v1/thread:280:5 (bitcoind+0x157e6a)
      OmniLayer#19 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (*)(char const*, std::__1::function<void ()>), char const*, AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7> >(void*) /usr/lib/llvm-13/bin/../include/c++/v1/thread:291:5 (bitcoind+0x157e6a)
    Previous read of size 8 at 0x7b3c000008f0 by main thread:
      #0 std::__1::vector<CBlockIndex*, std::__1::allocator<CBlockIndex*> >::size() const /usr/lib/llvm-13/bin/../include/c++/v1/vector:680:61 (bitcoind+0x15179d)
      OmniLayer#1 CChain::Tip() const src/./chain.h:449:23 (bitcoind+0x15179d)
      OmniLayer#2 ChainstateManager::ActiveTip() const src/./validation.h:927:59 (bitcoind+0x15179d)
      OmniLayer#3 AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*) src/init.cpp:1841:35 (bitcoind+0x15179d)
      OmniLayer#4 AppInit(node::NodeContext&, int, char**) src/bitcoind.cpp:231:43 (bitcoind+0x133fd2)
      OmniLayer#5 main src/bitcoind.cpp:275:13 (bitcoind+0x133fd2)
    Location is heap block of size 232 at 0x7b3c00000870 allocated by main thread:
      #0 operator new(unsigned long) <null> (bitcoind+0x132668)
      OmniLayer#1 ChainstateManager::InitializeChainstate(CTxMemPool*, std::__1::optional<uint256> const&) src/validation.cpp:4851:21 (bitcoind+0x48e26b)
      OmniLayer#2 node::LoadChainstate(bool, ChainstateManager&, CTxMemPool*, bool, Consensus::Params const&, bool, long, long, long, bool, bool, std::__1::function<bool ()>, std::__1::function<void ()>) src/node/chainstate.cpp:31:14 (bitcoind+0x24de07)
      OmniLayer#3 AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*) src/init.cpp:1438:32 (bitcoind+0x14e994)
      OmniLayer#4 AppInit(node::NodeContext&, int, char**) src/bitcoind.cpp:231:43 (bitcoind+0x133fd2)
      OmniLayer#5 main src/bitcoind.cpp:275:13 (bitcoind+0x133fd2)
    Mutex M131626 (0x7b3c00000898) created at:
      #0 pthread_mutex_lock <null> (bitcoind+0xda898)
      OmniLayer#1 std::__1::mutex::lock() <null> (libc++.so.1+0x49f35)
      OmniLayer#2 node::ThreadImport(ChainstateManager&, std::__1::vector<fs::path, std::__1::allocator<fs::path> >, ArgsManager const&) src/node/blockstorage.cpp:883:30 (bitcoind+0x23cd74)
      OmniLayer#3 AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7::operator()() const src/init.cpp:1657:9 (bitcoind+0x15863e)
      OmniLayer#4 decltype(static_cast<AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7&>(fp)()) std::__1::__invoke<AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7&>(AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7&) /usr/lib/llvm-13/bin/../include/c++/v1/type_traits:3918:1 (bitcoind+0x15863e)
      OmniLayer#5 void std::__1::__invoke_void_return_wrapper<void, true>::__call<AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7&>(AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7&) /usr/lib/llvm-13/bin/../include/c++/v1/__functional/invoke.h:61:9 (bitcoind+0x15863e)
      OmniLayer#6 std::__1::__function::__alloc_func<AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7, std::__1::allocator<AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7>, void ()>::operator()() /usr/lib/llvm-13/bin/../include/c++/v1/__functional/function.h:171:16 (bitcoind+0x15863e)
      OmniLayer#7 std::__1::__function::__func<AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7, std::__1::allocator<AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7>, void ()>::operator()() /usr/lib/llvm-13/bin/../include/c++/v1/__functional/function.h:345:12 (bitcoind+0x15863e)
      OmniLayer#8 std::__1::__function::__value_func<void ()>::operator()() const /usr/lib/llvm-13/bin/../include/c++/v1/__functional/function.h:498:16 (bitcoind+0x88891f)
      OmniLayer#9 std::__1::function<void ()>::operator()() const /usr/lib/llvm-13/bin/../include/c++/v1/__functional/function.h:1175:12 (bitcoind+0x88891f)
      OmniLayer#10 util::TraceThread(char const*, std::__1::function<void ()>) src/util/thread.cpp:18:9 (bitcoind+0x88891f)
      OmniLayer#11 decltype(static_cast<void (*>(fp)(static_cast<char const*>(fp0), static_cast<AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7>(fp0))) std::__1::__invoke<void (*)(char const*, std::__1::function<void ()>), char const*, AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7>(void (*&&)(char const*, std::__1::function<void ()>), char const*&&, AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7&&) /usr/lib/llvm-13/bin/../include/c++/v1/type_traits:3918:1 (bitcoind+0x157e6a)
      OmniLayer#12 void std::__1::__thread_execute<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (*)(char const*, std::__1::function<void ()>), char const*, AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7, 2ul, 3ul>(std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (*)(char const*, std::__1::function<void ()>), char const*, AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7>&, std::__1::__tuple_indices<2ul, 3ul>) /usr/lib/llvm-13/bin/../include/c++/v1/thread:280:5 (bitcoind+0x157e6a)
      OmniLayer#13 void* std::__1::__thread_proxy<std::__1::tuple<std::__1::unique_ptr<std::__1::__thread_struct, std::__1::default_delete<std::__1::__thread_struct> >, void (*)(char const*, std::__1::function<void ()>), char const*, AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7> >(void*) /usr/lib/llvm-13/bin/../include/c++/v1/thread:291:5 (bitcoind+0x157e6a)
    Mutex M151 (0x55aacb8ea030) created at:
      #0 pthread_mutex_init <null> (bitcoind+0xbed2f)
      OmniLayer#1 std::__1::recursive_mutex::recursive_mutex() <null> (libc++.so.1+0x49fb3)
      OmniLayer#2 __libc_start_main <null> (libc.so.6+0x29eba)
    Mutex M131553 (0x7b4c000042e0) created at:
      #0 pthread_mutex_init <null> (bitcoind+0xbed2f)
      OmniLayer#1 std::__1::recursive_mutex::recursive_mutex() <null> (libc++.so.1+0x49fb3)
      OmniLayer#2 std::__1::__unique_if<CTxMemPool>::__unique_single std::__1::make_unique<CTxMemPool, CBlockPolicyEstimator*, int const&>(CBlockPolicyEstimator*&&, int const&) /usr/lib/llvm-13/bin/../include/c++/v1/__memory/unique_ptr.h:728:32 (bitcoind+0x15c81d)
      OmniLayer#3 AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*) src/init.cpp:1426:24 (bitcoind+0x14e7b4)
      OmniLayer#4 AppInit(node::NodeContext&, int, char**) src/bitcoind.cpp:231:43 (bitcoind+0x133fd2)
      OmniLayer#5 main src/bitcoind.cpp:275:13 (bitcoind+0x133fd2)
    Thread T22 'b-loadblk' (tid=32370, running) created by main thread at:
      #0 pthread_create <null> (bitcoind+0xbd5bd)
      OmniLayer#1 std::__1::__libcpp_thread_create(unsigned long*, void* (*)(void*), void*) /usr/lib/llvm-13/bin/../include/c++/v1/__threading_support:443:10 (bitcoind+0x155e06)
      OmniLayer#2 std::__1::thread::thread<void (*)(char const*, std::__1::function<void ()>), char const (&) [8], AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7, void>(void (*&&)(char const*, std::__1::function<void ()>), char const (&) [8], AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*)::$_7&&) /usr/lib/llvm-13/bin/../include/c++/v1/thread:307:16 (bitcoind+0x155e06)
      OmniLayer#3 AppInitMain(node::NodeContext&, interfaces::BlockAndHeaderTipInfo*) src/init.cpp:1656:29 (bitcoind+0x150164)
      OmniLayer#4 AppInit(node::NodeContext&, int, char**) src/bitcoind.cpp:231:43 (bitcoind+0x133fd2)
      OmniLayer#5 main src/bitcoind.cpp:275:13 (bitcoind+0x133fd2)
  SUMMARY: ThreadSanitizer: data race /usr/lib/llvm-13/bin/../include/c++/v1/__utility/swap.h:39:7 in std::__1::enable_if<(is_move_constructible<CBlockIndex**>::value) && (is_move_assignable<CBlockIndex**>::value), void>::type std::__1::swap<CBlockIndex**>(CBlockIndex**&, CBlockIndex**&)
  ==================
  ```

  From https://cirrus-ci.com/task/5612886578954240?logs=ci#L4868

ACKs for top commit:
  achow101:
    re-ACK fac04cb
  theStack:
    Code-review ACK fac04cb

Tree-SHA512: 9d619f99ff6373874c7ffe1db20674575605646b4b54b692fb54515a4a49f110a770026d7320ed6dfeaa7976be4cd89e93f821acdbf22c7662bd1c5be0cedcd2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants