A curated list of awesome C frameworks, libraries and software.
The Patterns of Scalable, Reliable, and Performant Large-Scale Systems
The Swift Programming Language
1ML prototype interpreter
Official repository for 8086tiny: a tiny PC emulator/virtual machine
Nominal Adapton in Rust
aHash is a non-cryptographic hashing algorithm that uses the AES hardware instruction
A functional programming language based on Standard ML, extended with support for concurrent, distributed, and constraint programming
graydon/alternative-internet 0
A collection of interesting new networks and tech aiming at decentralisation (in some form).
SyncFree Reference Platform
pull request commentstellar/stellar-core
Add backtrace-printing machinery and use it in GlobalChecks asserts.
Pushed variant with a fair number of suggested fixes, though some weren't possible. See notes inline above.
comment created time in 3 days
Pull request review commentstellar/stellar-core
Add backtrace-printing machinery and use it in GlobalChecks asserts.
printErrorAndAbort(const char* s1) { std::fprintf(stderr, "%s\n", s1); std::fflush(stderr);+ printBacktrace();
I tried to make this work for several hours but there are a bunch of wrinkles
- trapping
SIGABRTitself in asio just .. doesn't seem to work, and I can't tell why; spent a while in a debugger and couldn't figure it out - trapping all the other core-dump / fatal signals seems to work but only if tracy is disabled, otherwise it interferes by registering its own handlers
- either way trapping signals doesn't handle the
releaseAssertOrThrowcase anyways because that unwinds before it calls terminate, losing the backtrace
Overall I've opted to leave something useful if not universal in here. We might want to do a followup later for trapping SIGSEGV or something but in general this works for the releaseAssert and releaseAssertOrThrow cases which I think are worthwhile.
comment created time in 3 days
Pull request review commentstellar/stellar-core
Add backtrace-printing machinery and use it in GlobalChecks asserts.
+// Copyright 2020 Stellar Development Foundation and contributors. Licensed+// under the Apache License, Version 2.0. See the COPYING file at the root+// of this distribution or at http://www.apache.org/licenses/LICENSE-2.0++#include "util/Backtrace.h"++#ifdef _WIN32
fixed
comment created time in 3 days
Pull request review commentstellar/stellar-core
Add backtrace-printing machinery and use it in GlobalChecks asserts.
AC_ARG_ENABLE(easylogging, [Disable easylogging])) AM_CONDITIONAL(USE_EASYLOGGING, [test x$enable_easylogging != xno]) +case "${host_os}" in+ *darwin*)+ # libunwind comes standard with the command-line tools on macos+ ;;+ *)+ PKG_CHECK_MODULES(libunwind, libunwind)
fixed
comment created time in 3 days
push eventgraydon/stellar-core
commit sha 6658954124b14e3f69a5ddcc36a99a43e6f0145c
Add backtrace-printing machinery and use it in GlobalChecks asserts.
push time in 3 days
Pull request review commentstellar/stellar-core
Add backtrace-printing machinery and use it in GlobalChecks asserts.
#include <stdexcept> #include <thread> +namespace+{+void+printBacktrace()
sure, I'll make it a single function that prints while unwinding, rather than a pair that allocates a vector and another that consumes it.
comment created time in 3 days
Pull request review commentstellar/stellar-core
Add backtrace-printing machinery and use it in GlobalChecks asserts.
+// Copyright 2020 Stellar Development Foundation and contributors. Licensed+// under the Apache License, Version 2.0. See the COPYING file at the root+// of this distribution or at http://www.apache.org/licenses/LICENSE-2.0++#include "util/Backtrace.h"++#ifdef _WIN32++// Backtrace-generation is not suported on windows.+std::vector<std::string>+getCurrentBacktrace()+{+ std::vector<std::string> res;+ return res;+}++#else++#define UNW_LOCAL_ONLY+#include <cxxabi.h>+#include <libunwind.h>++std::vector<std::string>+getCurrentBacktrace()+{+ std::vector<std::string> res;++ unw_context_t ctxt;+ if (unw_getcontext(&ctxt) != 0)+ {+ return res;+ }++ unw_cursor_t curs;+ if (unw_init_local(&curs, &ctxt) != 0)+ {+ return res;+ }++ char buf[1024];+ unw_word_t off;+ while (unw_step(&curs) > 0)+ {+ if (unw_get_proc_name(&curs, buf, sizeof(buf), &off) != 0)+ {+ continue;+ }+ int status = 0;+ char* demangled = abi::__cxa_demangle(buf, nullptr, nullptr, &status);+ if (status == 0)+ {+ res.emplace_back(demangled);
I'm happy to avoid possibly-throwing paths but as mentioned above, will need at least to be able to malloc and free.
comment created time in 3 days
Pull request review commentstellar/stellar-core
Add backtrace-printing machinery and use it in GlobalChecks asserts.
+// Copyright 2020 Stellar Development Foundation and contributors. Licensed+// under the Apache License, Version 2.0. See the COPYING file at the root+// of this distribution or at http://www.apache.org/licenses/LICENSE-2.0++#include "util/Backtrace.h"++#ifdef _WIN32++// Backtrace-generation is not suported on windows.+std::vector<std::string>+getCurrentBacktrace()+{+ std::vector<std::string> res;+ return res;+}++#else++#define UNW_LOCAL_ONLY+#include <cxxabi.h>+#include <libunwind.h>++std::vector<std::string>+getCurrentBacktrace()+{+ std::vector<std::string> res;++ unw_context_t ctxt;
unw_backtrace just gets you the frame addresses; resolving them to names and demangling them requires more. the demangling function in particular expects to be given a malloc'ed buffer that it can realloc if it wants, and that the caller will free. I don't think we can really make this robust in the face of allocator corruption -- this is only going to work at all when we can at least allocate and free.
comment created time in 3 days
Pull request review commentstellar/stellar-core
Add backtrace-printing machinery and use it in GlobalChecks asserts.
#include <stdexcept> #include <thread> +namespace+{+void+printBacktrace()+{+ auto bt = getCurrentBacktrace();
I don't really understand what role a global plays here. If getCurrentBacktrace crashes there's no reason to believe we'll even return to printBacktrace.
comment created time in 3 days
Pull request review commentstellar/stellar-core
Add backtrace-printing machinery and use it in GlobalChecks asserts.
AC_ARG_ENABLE(easylogging, [Disable easylogging])) AM_CONDITIONAL(USE_EASYLOGGING, [test x$enable_easylogging != xno]) +case "${host_os}" in+ *darwin*)+ # libunwind comes standard with the command-line tools on macos
No, macos doesn't ship a pkg-config file for it (.pc) and it's also linked automatically and available in the standard include path (so no cflags or ldflags anyway).
comment created time in 3 days
Pull request review commentstellar/stellar-core
Add backtrace-printing machinery and use it in GlobalChecks asserts.
See the [dev container's README](.devcontainer/README.md) for more detail. - 64-bit system - `clang-format-5.0` (for `make format` to work) - `perl`+- `libunwind`
Fixed.
comment created time in 3 days
PR closed stellar/stellar-core
This changes the behaviour of the process manager to call sync(2) when a subprocess exits.
There are two purposes to this:
- First -- the motivating purpose -- is to reduce spikes in dirty pages (still being written to disk) that happen when running large-ish test workloads on kubernetes; these spikes seem to provoke oom-kill events from the underlying kernel at unfortunate frequency.
- Second, it may also close a small node-local data corruption gap should there be a power loss or node reboot during such a period of transient data. This is unlikely (we only usually run a slew of
getcommands once during catchup) but it's a possible failure mode and it's always nice to remove a few more of those.
As with the fsync-on-xdr-stream-close change, this change is accompanied by a config variable you can use to disable the behaviour should you need to (eg. on a super-slow spinning disk) but it seems even less likely to ever be needed here.
pr closed time in 3 days
pull request commentstellar/stellar-core
Sync filesystem changes after subprocess exit
Closing. Going to solve this via fiddling with /proc/sys/vm/dirty_bytes
comment created time in 3 days
pull request commentstellar/stellar-core
Sync filesystem changes after subprocess exit
I've pushed a variant here that does what you suggested -- calls fsync on a file it reopened -- and have run it through the k8s cluster job in question. It does not appear to work: same dirty-page spikes we were seeing before. I guess fsync is only able to act on pages dirtied by a specific file handle not "any file handle pointing to the same file", whatever "same file" means at that level (inode? copy-of-file-in-memory? who knows).
I'll keep testing, it's possible I have a bug in my implementation here, but for the time being sync() is the only thing that works.
comment created time in 4 days
Pull request review commentstellar/stellar-core
Add backtrace-printing machinery and use it in GlobalChecks asserts.
AC_ARG_ENABLE(easylogging, [Disable easylogging])) AM_CONDITIONAL(USE_EASYLOGGING, [test x$enable_easylogging != xno]) +case "${host_os}" in+ *darwin*)+ # libunwind comes standard with the command-line tools on macos
The headers are also present as standard on macos.
comment created time in 4 days
push eventgraydon/stellar-core
commit sha 1878a9a6844ab136ed42fa6c259aaefd75fd92e0
Address review comments - use fsync on single file.
push time in 4 days
Pull request review commentstellar/stellar-core
Sync filesystem changes after subprocess exit
ProcessManagerImpl::handleSignalWait() const int status = std::get<1>(pidStatus); handleProcessTermination(pid, status); }+ if (mSyncFilesystemOnProcessExit)
It does indeed get executed on the main thread -- that's the whole point, to block the main thread from doing more allocation / launching more processes / causing more VM pressure until existing dirty pages are written.
I'm not entirely sure what you're concerned about here: flushing too many filesystems besides the one we're intending to? Or flushing files on that filesystem that aren't necessary to flush?
fsync on a file flushes changes to that file -- we certainly could just fsync the file that was transferred by (say) each get() command, that might be sufficient to relieve the pressure we're encountering, might not. In theory it should be but it's hard to tell.
I think (trying to read between the lines of the man page) that opening a recently-written file -- even one written by a different process -- then calling fsync and closing it will in fact flush dirty pages associated with that file to the disk. I mean, I can try it and see anyways. If you prefer to do this narrower single-file version, I will try that.
syncfs is the same as sync but on a single filesystem. So it's a bit in-between sync (all filesystems) and fsync (one file). I'm not sure it's worth bothering to split that hair, since we're probably running on a single-filesystem node anyways (or only have one filesystem with much dirty data). Also syncfs isn't portable to macos or BSD.
comment created time in 4 days
startedGaloisInc/crucible
started time in 4 days
startedibireme/yyjson
started time in 5 days
startedrudymatela/leancheck
started time in 5 days
startedAltSysrq/proptest
started time in 5 days
pull request commentstellar/stellar-core
Add backtrace-printing machinery and use it in GlobalChecks asserts.
Also I did not print the backtrace to/via the logging facility. I could do so if you like. Currently printing to stderr directly, to avoid the possibility of the logging facility itself failing / being broken.
comment created time in 5 days
PR opened stellar/stellar-core
This adds a backtrace-gathering function and wires it in to the assert functions in GlobalChecks.h so that when a releaseAssert or a releaseAssertOrThrow check fails, we get something like this (as an synthetic example of adding releaseAssertOrThrow(false)):
false at herder/QuorumTracker.cpp:38
backtrace:
0: (anonymous namespace)::printBacktrace()
1: stellar::printAssertFailureAndThrow(char const*, char const*, int)
2: stellar::QuorumTracker::expand(stellar::PublicKey const&, std::shared_ptr<stellar::SCPQuorumSet>)
3: stellar::QuorumTracker::rebuild(std::function<std::shared_ptr<stellar::SCPQuorumSet> (stellar::PublicKey const&)>)
4: stellar::PendingEnvelopes::isNodeDefinitelyInQuorum(stellar::PublicKey const&)
5: stellar::PendingEnvelopes::recvSCPEnvelope(stellar::SCPEnvelope const&)
6: stellar::HerderImpl::recvSCPEnvelope(stellar::SCPEnvelope const&)
7: stellar::Peer::recvSCPMessage(stellar::StellarMessage const&)
8: stellar::Peer::recvRawMessage(stellar::StellarMessage const&)
9: std::_Function_handler<void (), stellar::Peer::recvMessage(stellar::StellarMessage const&)::$_1>::_M_invoke(std::_Any_data const&)
10: stellar::Scheduler::ActionQueue::runNext(stellar::VirtualClock&, std::chrono::duration<long, std::ratio<1l, 1000000000l> >)
11: stellar::Scheduler::runOne()
12: stellar::VirtualClock::crank(bool)
13: stellar::runWithConfig(stellar::Config, std::shared_ptr<stellar::CatchupConfiguration>)
14: std::_Function_handler<int (), stellar::run(stellar::CommandLineArgs const&)::$_22>::_M_invoke(std::_Any_data const&)
15: stellar::(anonymous namespace)::runWithHelp(stellar::CommandLineArgs const&, std::vector<stellar::(anonymous namespace)::ParserWithValidation, std::allocator<stellar::(anonymous namespace)::ParserWithValidation> >, std::function<int ()>)
16: stellar::run(stellar::CommandLineArgs const&)
17: stellar::handleCommandLine(int, char* const*)
18: __libc_start_main
19: _start
2020-10-21T17:52:50.181 GBUPX [default FATAL] Got an exception: false [ApplicationUtils.cpp:121]
terminate called after throwing an instance of 'std::runtime_error'
what(): false
Aborted (core dumped)
This does add a requirement for libunwind to the build on macos and linux -- I could do a little more configury to make it optional but it seemed to me like we probably want to make it mandatory as it's quite useful and readily available. Up to reviewers to decide, I'm happy either way. Will need to update the package-building scripts if we accept it as mandatory (or merely want to ship it commonly, either way).
pr created time in 5 days
push eventgraydon/stellar-core
commit sha 492451cce6ac603f1c256eebfd412b4d721f7165
Add backtrace-printing machinery and use it in GlobalChecks asserts.
push time in 5 days
push eventgraydon/stellar-core
commit sha 1500c342199b48d5e79c2f646a8917b75e4ce5ab
Sync filesystem changes caused by processes.
push time in 6 days
startedianlancetaylor/libbacktrace
started time in 6 days
startedhidenori-shinohara/stellar-ivy
started time in 6 days
PR opened stellar/stellar-core
Experimenting with ways of adjusting the working set of a core container
pr created time in 7 days
startedjonsterling/dreamtt
started time in 9 days
startedranjitjhala/sprite-lang
started time in 9 days
pull request commentstellar/stellar-core
Fix deadlock in verify-checkpoints command
Pushed update with fixes to comments.
comment created time in 11 days
push eventgraydon/stellar-core
commit sha a3ab655550ce4b88ae47d530f450340e6989fd03
Fix test to exercise inter-work future propagation, catching bug #2757.
commit sha c758b6664c4a97a347e8667999995eb355d00af4
Add and use futureIsReady helper, fixing bug #2757. Accidentally treated call to shared_future.valid() as a test for readiness in a guard for an assert. The assert then called .get() on a non-ready future, deadlocking. Fix is to replace this with a proper helper that tests readiness and replace instances of readiness-testing with calls to helper.
commit sha b31a33498ac7f26db729565712060e478c373875
Change a bunch of asserts to releaseAsserts.
push time in 11 days
Pull request review commentstellar/stellar-core
Fix deadlock in verify-checkpoints command
TEST_CASE("write verified checkpoint hashes", "[historywork]") catchupSimulation.getClock().crank(); } - Hash h = WriteVerifiedCheckpointHashesWork::loadHashFromJsonOutput(- pair.first, file);- REQUIRE(h == *pair.second);+ for (auto const& p : pairs)+ {+ LOG(INFO) << "Verified " << p.first << " with hash "
Fixed.
comment created time in 11 days
Pull request review commentstellar/stellar-core
Fix deadlock in verify-checkpoints command
VerifyLedgerChainWork::VerifyLedgerChainWork( , mVerifyLedgerChainFailure(app.getMetrics().NewMeter( {"history", "verify-ledger-chain", "failure"}, "event")) {- if (trustedMaxLedger.valid())+ if (futureIsReady(trustedMaxLedger))
Fair enough. Fixed.
comment created time in 11 days
PR opened stellar/stellar-core
Description
The "deadlock" in bug #2757 was just mistakenly treating .valid() as meaning "future is ready" when guarding an assert.
Existing testcase didn't trap this because while I thought it did 5 inner works because it did 5 checkpoints (and thus exercised the inter-work propagation code) I forgot that I also did batching for parallelism inside the outer work (to keep the network saturated with downloads) and so all 5 checkpoints were verified by a single inner work, this actually wasn't testing the inter-work propagation code on the inner works at all. So I changed the outer work to allow changing the batching factor (to avoid having to make the test run a long time) and then fixed the test to run 5 * the batching factor.
Once the test is corrected, the fix is straightforward: just add a helper called futureIsReady that does the (honesty somewhat silly) wait-for-a-nanosecond thing one has to do to check future readiness, and use it instead. Also replace other places in the code we do the same silly wait.
pr created time in 12 days
push eventgraydon/stellar-core
commit sha 9b2e9b4b253c5876d7868ad13f14e2c69f9d012a
Fix test to exercise inter-work future propagation, catching bug #2757.
commit sha 6e9946dae2827e1c408db5a2ee8f212b5dbbf5c4
Add and use futureIsReady helper, fixing bug #2757. Accidentally treated call to shared_future.valid() as a test for readiness in a guard for an assert. The assert then called .get() on a non-ready future, deadlocking. Fix is to replace this with a proper helper that tests readiness and replace instances of readiness-testing with calls to helper.
push time in 12 days
create barnchgraydon/stellar-core
branch : bug-2757-verify-checkpoints-deadlock
created branch time in 12 days
startedKDAB/hotspot
started time in 12 days
push eventgraydon/stellar-core
commit sha 6e3b4cfc1fedc4bb0cf93d96440b89dd5e23adfa
Try the other way with giant IO buffers
push time in 14 days
push eventgraydon/stellar-core
commit sha faae1b53e86690543a8ed20ee39ad8937a1dd70f
revert timer constant tweaks
commit sha 3dc74262502dcc096281224ba399e08f2e4cbab0
Lower TCPPeer BUFSZ to 4k
push time in 14 days
push eventgraydon/stellar-core
commit sha 187ccc4179bd7aa1090f7586ce4d97a092ddc9fe
Try low latency and low time slice simultaneously
push time in 14 days
push eventgraydon/stellar-core
commit sha a985005fe9155ffdb32d7f6f27a7b13c698864f7
Lower CRANK_TIME_SLICE back to 10ms.
push time in 17 days
push eventgraydon/stellar-core
commit sha 97928bab6d9aa1cc25f1a182727e95742cd1ff84
Restore time slice and latency window, increase CRANK_EVENT_SLICE from 100 to 1000.
push time in 17 days
issue commentstellar/stellar-core
Can/should we just put this under the general heading "switch to Quill"?
comment created time in 17 days
push eventgraydon/stellar-core
commit sha f52af3ae6550771ac967cea4979eb7d1d73f871a
Reduce CRANK_TIME_SLICE from 500ms to 10ms.
push time in 17 days
push eventgraydon/stellar-core
commit sha 50f8fb70c00b1c32e2746cc894e9dfbab40e8a29
Reduce SCHEDULER_LATENCY_WINDOW to 1 second
push time in 18 days
PR opened stellar/stellar-core
WIP PR-branch for testing various attempts at queue reduction
pr created time in 18 days
startedjandrewrogers/AquaHash
started time in 20 days
startedCyan4973/xxHash
started time in 20 days
fork graydon/aHash
aHash is a non-cryptographic hashing algorithm that uses the AES hardware instruction
fork in 20 days
startedtkaitchuck/aHash
started time in 20 days
startedproject-oak/oak
started time in 21 days
pull request commentstellar/stellar-core
Hmm, the previous hunk looks fairly intentional. I do not remember the intent -- but are you sure it's wrong?
comment created time in a month
PR opened calccrypto/uint128_t
If these methods are not marked const, they call themselves in their implementation rather than the const-qualified uint128_t base cases.
pr created time in a month
push eventgraydon/uint128_t
commit sha f3d24420fb971d51ac247271163d3a3c7ac409fe
Fix infinite recursion If these methods are not marked const, they call themselves in their implementation rather than the const-qualified uint128_t base cases.
push time in a month
PR opened stellar/stellar-core
This updates uint128_t from upstream primarily to incorporate a bit more-reasonable code to deal with cases where a uint128_t is initialized from a negative number. Previously it would initialize to a (perhaps surprising!) UINT64_MAX -- that is, sign-extending only to the width of the lower of its two fields -- whereas the probably-more-sensible thing to do is sign extend across both fields.
For even-more-safety sake, I've also made the entire behaviour of sign-extending when given a negative signed input throw by default, as it's very likely an error: nothing in core does so currently, and we should already have checks on all paths converting from signed types that we're dealing with non-negative inputs. This just firms it up a bit.
pr created time in a month
create barnchgraydon/stellar-core
branch : uint128-t-misuse-prevention
created branch time in a month
startedchjj/liburkel
started time in a month
startedjellyfin/jellyfin
started time in a month
PR opened stellar/stellar-core
just absorb a couple 2-liner stdlib spec-compliance fixes in xdrpp.
pr created time in a month
startedezrakilty/narc
started time in a month
startedwithoutboats/maglev
started time in a month
startedearthstar-project/earthstar
started time in a month
startedmozilla/uniffi-rs
started time in a month
startedtsung-ju/SystemF
started time in a month
startededn-format/edn
started time in a month
startedsignalapp/libsignal-protocol-rust
started time in a month
startedkoka-lang/koka
started time in a month
fork graydon/awesome-leading-and-managing
Awesome List of resources on leading people and being a manager. Geared toward tech, but potentially useful to anyone.
fork in a month
startedLappleApple/awesome-leading-and-managing
started time in a month
pull request commentstellar/stellar-core
add new option to `catchup` command to active http endpoint
Hmm, unsure; I might prefer to do it via the existing HTTP_PORT / PUBLIC_HTTP_PORT config settings? I mean, I guess the question is whether those config settings implicitly mean ".. only when doing run, not catchup"?
What exactly is going wrong with the previous change?
comment created time in a month
push eventgraydon/stellar-core
commit sha 678c21908c830176431c2a4372fd7a2a153513f1
Bump tracy submodule and build with -DTRACY_ONLY_IPV4
commit sha b6a1b5c8bd8f04398f3f5df944a39460589515ad
Replace an unordered_set in SurveyManager with a queue
commit sha ba1fb28efcefab113a51f8e2801b6ebb612cf358
Add comments and clarify finalization of incremental SipHash.
commit sha 52c21ef3f16e660b740103abbd16d9eb8793db25
Make --disable-easylogging build on linux.
commit sha 1ee27952a680e6c92f8500e7ff90e085a4403ea8
Merge pull request #2668 from hidenori-shinohara/queue Replace an unordered_set in SurveyManager with a queue Reviewed-by: MonsieurNicolas
commit sha c641d0787ffd1d01f472a6b969b5e8d04710d6cf
Merge pull request #2684 from graydon/tracy-ipv4-only Bump tracy submodule and build with -DTRACY_ONLY_IPV4 Reviewed-by: MonsieurNicolas
commit sha 07d19983a092b16322a5427be43b1fd46b1d123d
Avoid spec-violating memcpy with nullptr in 0-byte case.
commit sha 2ee1a89638f87d5583402f5f7caf2406d20f47da
Merge pull request #2702 from graydon/siphash-comment-and-clarification Small cleanups and comments Reviewed-by: graydon
commit sha 9cdf15347b1a5df650be4962d4891ff71a988f92
Un-inline Bucket::checkProtocolLegality() It's referenced from translation units other than the one in which it's defined.
commit sha 49ca31fd1831203d4ac6b9b55bb5d667eb3783ab
Merge pull request #2705 from rokopt/un-inline-bucket-check-protocol-legality Un-inline Bucket::checkProtocolLegality() Reviewed-by: MonsieurNicolas
commit sha 89aefb04e39869a7e4464959e3fd64a685a76be0
Refactor LedgerTxnRoot::getBestOffers to share code
commit sha c2d8e3cea41f50df177ce98fcadb4cec13cd5b0d
Merge pull request #2706 from jonjove/get-best-offers Refactor LedgerTxnRoot::getBestOffers to share code Reviewed-by: MonsieurNicolas
commit sha d11bf4f86362fe0a4ce76a2a7bd169da696c0113
Add --in-memory option, deprecate --replay-in-memory.
commit sha b1d3e9644373e1dfd6d3a4ef62646d9099c094b6
Add --in-memory support to "run" command.
commit sha 820864dcd8321e4826b24563a7bf3b65e3c88544
Add no-op args for --start-at-{ledger,hash}
commit sha 7ed052c775fae20c4e47a352d2205a93e5ab295e
Wire up catchup-before-run arguments.
commit sha 36c5eef84b529aff880da769009683b6174019fc
Update docs
push time in a month
Pull request review commentstellar/stellar-core
Bug 2634 run in memory from checkpoint
runWithConfig(Config cfg) << "(for testing only)"; } - app->start();+ if (cc)+ {+ Json::Value catchupInfo;+ std::shared_ptr<HistoryArchive> archive;+ auto const& ham = app->getHistoryArchiveManager();+ archive = ham.selectRandomReadableHistoryArchive();+ if (catchup(app, *cc, catchupInfo, archive) == 0)+ {+ // Pre-run catchup defers overlay startup.
Yes, fixed.
comment created time in a month
Pull request review commentstellar/stellar-core
Bug 2634 run in memory from checkpoint
runWithConfig(Config cfg) << "(for testing only)"; } - app->start();+ if (cc)+ {+ Json::Value catchupInfo;+ std::shared_ptr<HistoryArchive> archive;+ auto const& ham = app->getHistoryArchiveManager();+ archive = ham.selectRandomReadableHistoryArchive();+ if (catchup(app, *cc, catchupInfo, archive) == 0)+ {+ // Pre-run catchup defers overlay startup.+ app->getOverlayManager().start();+ }+ else+ {+ return 1;
Yep, good call. Fixed.
comment created time in a month