I am writing a C++ server program that will be deployed to *nix systems (Linux/macOS). The program sometimes runs into segfault in production environment, and I would like to collect some information like core dump file. But I have no idea what the best practice is for doing this:
I learn that there are some things I could try:
RelWithDebInfo
and Release
for CMAKE_BUILD_TYPE
, but it seems they have different optimization level. So I assume RelWithDebInfo
build performs not as well as Release
build. (“RelWithDebInfo uses -O2, but Release uses -O3“ according to here What are CMAKE_BUILD_TYPE: Debug, Release, RelWithDebInfo and MinSizeRel?)objectcopy
/strip
allow you to strip debug information from a binary (How to generate gcc debug symbol outside the build target?)SIGSEGV
signal (How to automatically generate a stacktrace when my program crashes)I am new to deploy a production C++ server program, and I would like to know the answers for the following questions:
RelWithDebInfo
or Release
?strip
?Release
build binary for production deployment, when the Release
build generates a core dump in production environment, can I later use the using the same revision of source code to build a RelWithDebInfo
binary and use (gdb + RelWithDebInfo
binary + Release
build core dump) for core dump analysis?In general, I would like to know how C++ programs is recommended to be build for production, allowing it to be best optimized while I am still able to troubleshoot it. Thanks so much.
This will be a rather general answer.
RelWithDebInfo
. Alternatively, you can override -O2
optimization to get the compiler to optimize all the way.strip
when debug info is present. This doesn't change any of the stuff that actually gets executed, but removes things that make debugging much easier. You can still debug stripped executables, but it is more difficult to understand what is going on.The general rule is (or should be) that you consider release environment as hostile. Sometimes that is true, sometimes it is not -- here generality can't apply because only you know your specific situation.
I always deploy my stuff fully optimized. I will only include debug info if a program is particularly problematic, because it makes it easy to either run it with or attach to it using gdb
.
The downside of full optimization is that things sometimes look a bit different than the code you wrote. Order of things may change, some things may not happen at all, and you may observe that some functions don't really exist as proper standalone functions because compiler decides they are better off being inlined. These are changes I observed, but there are probably others as well.