Open-source graph database, built for real-time streaming data, compatible with Neo4j.
cyphergraphgraph-algorithmsgraph-analysisgraph-databasekafkakafka-streamsnosqlopencypherstream-processingstreaming-data
527d69d382
Summary:
There were a couple of issues with handling the above 2 signals.
1) Calling `std::exit` from a signal handler is undefined behaviour.
The only defined way for a signal handler to stop the program is calling
one of: `std::_Exit`, `std::abort` or `std::quick_exit`. Neither of them
will completely clean the resources, so a clean exit is not possible.
Since SIGSEGV and SIGABRT happen in extraordinary circumstances that we
wish to debug 99% of the time, it makes sense to generate a core dump
which can be inspected by a debugger. Of the 3 termination functions,
only `std::abort` will generate a core dump, so it makes sense to use
that to stop the program.
Also, since we are now aborting as is the default behaviour on SIGSEGV
and SIGABRT, it becomes questionable why have a custom handler at all.
2) Raising an exception inside a signal handler is undefined behaviour
Although the handler by itself does not raise an exception, it is
possible for the logging facility to raise one. This is a real case when
logging a stack trace in particular. Stack trace is generated by
creating a string "<function name> <line location>". It is possible that
a function name will contain '{}' somewhere inside. This is usually the
case with anonymous functions. The generated string is then passed to
logging, which uses the `fmt` library to fill '{}' with remaining
arguments. Since only a single argument (the stack trace string) is
passed for formatting, naturally the `fmt::format` throws an exception,
that it is missing a format argument.
We could provide an overload which takes a single string, but that
defeats the purpose of `fmt::format` raising an exception in regular
code if we forget to pass an argument. Another solution is to escape the
whole stack trace string, so it is valid for formatting, but this only
complicates the handler even further. The simplest solution is to send
the stack trace to `stderr` and avoid logging altogether.
Simplify Shutdown, so it can be used in a signal handler
Reviewers: florijan, mferencevic, buda, mislav.bradac
Reviewed By: mferencevic, buda
Subscribers: pullbot
Differential Revision: https://phabricator.memgraph.io/D474
|
||
|---|---|---|
| cmake | ||
| config | ||
| docs | ||
| libs | ||
| poc | ||
| release | ||
| src | ||
| tests | ||
| tools/gdb-plugins | ||
| .arcconfig | ||
| .clang-format | ||
| .gdbinit | ||
| .gitignore | ||
| .ycm_extra_conf.py | ||
| CHANGELOG.md | ||
| CMakeLists.txt | ||
| coverage | ||
| Doxyfile | ||
| Doxylogo.png | ||
| format | ||
| init | ||
| llvm-gcov | ||
| README.md | ||
memgraph
Memgraph is an ACID compliant high performance transactional distributed in-memory graph database featuring runtime native query compiling, lock free data structures, multi-version concurrency control and asynchronous IO.
dependencies
Memgraph can be compiled using any modern c++ compiler. It mostly relies on the standard template library, however, some things do require external libraries.
Some code contains linux-specific libraries and the build is only supported on a 64 bit linux kernel.
- linux
- clang 3.8 (good c++11 support, especially lock free atomics)
- antlr (compiler frontend)
- cppitertools
- fmt format
- google benchmark
- google test
- yaml-cpp