|Version 23 (modified by dmisev, 6 weeks ago) (diff)|
Debugging and Benchmarking Support
The rasdaman code has facilities built in which aid debugging and benchmarking. On this page information is collected on how to use it. Target audience are experienced C++ programmers.
It is a good idea to configure Rasdaman using cmake (v3+) with the following option:-DCMAKE_CXX_FLAGS=" -O0 -g3 -gdwarf-2 -rdynamic". (For autotools, you would use the following options: --with-debug-symbols --with-optimization=0)
Furthermore, in rasnet (the default network protocol), in order to attach to the rasserver process (with e.g. gdb -p <rasserver pid>) it is necessary to increase the values of SERVER_MANAGER_CLEANUP_INTERVAL and CLIENT_MANAGER_CLEANUP_INTERVAL in source:rasmgr_x/src/constants.hh to large values.
When not debugging the network protocol, it's recommended to use directql, which is a single executable rasserver utilizing no client/server protocol, instead of rasql.
directql has the same interface as rasql, with an important behind the scenes difference: it is a fully fledged rasserver itself actually, so it doesn't need to go through the client protocol. This makes it ideal for running tools like gdb, valgrind, etc.
Rasdaman should be configured and installed without optimization (level: 0) (http://stackoverflow.com/a/1778700/2028440), otherwise gdb and other tools will be barely useful.
- If you use cmake to compile (http://rasdaman.org/wiki/InstallFromSource/cmake):
// You can add the flags for g++ by adding these values in DCMAKE_CXX_FLAGS (e.g: -DCMAKE_CXX_FLAGS=" -O0 -g3 -gdwarf-2 -rdynamic" will append the optimization flag " -O0 -g3 -gdwarf-2 -rdynamic" in g++, where -O0 is equivalent to --with-optimization=0).
- If you use autotools to compile (deprecated):
./configure ...other options... --with-debug-symbols --with-optimization=0 make make install # restart rasdaman
When executing directql, use the same parameters as for rasql, but add -d /opt/rasdaman/data/RASBASE (or substitute that to whatever is the -connect value in rasmgr.conf).
Example with gdb:
gdb directql ... r -q 'query that causes a segfault' --out file -d /opt/rasdaman/data/RASBASE ... # show a backtrace once the segfault has happened bt
Valgrind can similarly be used to detect uninitialized values, memory errors, and memory leaks, e.g.
valgrind --leak-check=full --track-origins=yes directql -q 'query that causes memory problems' --out file -d /opt/rasdaman/data/RASBASE
Enabling extra output at compile time
In order to effect any extra output (besides standard logging) at all, the code must be compiled with the resp. option enabled. This is not default in production operation for at least two reasons: writing an abundance of lines into log files slows down performance somewhat, and, additionally, logging has a tendency to flood file systems; however, the option is available when needed.
If you are compiling with cmake (v3+), simply use -DENABLE_DEBUG before generating the build tree. Doing this includes the above cmake flags for debugging, and it also sets two other variables to enable more-verbose logging.
z.B. in CentOS 7, in your build directory
cmake3 $RASDAMAN_SOURCES -DCMAKE_INSTALL_PREFIX=$RMANHOME -DENABLE_DEBUG ...<other flags> make make install
You may, optionally, alter settings in $RMANHOME/etc/log-client.conf and $RMANHOME/etc/log-server.conf to enable various other logging parameters, e.g. TRACE for easier back tracing.
If you are using autotools (deprecated), the debug output option is chosen during the configuration step, which passes on this information to the compiler during the subsequent make.
./configure ...other options... --enable-debug --with-debug-symbols --with-optimization=0 make make install # restart rasdaman