wiki:DebuggingBenchmarking

Version 20 (modified by bbell, 3 weeks ago) (diff)

--

Note: this page is deprecated since rasdaman v9.2

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.

Debuging rasserver

It's a good idea to configure rasdaman with 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 that doesn't use any client/server protocol, instead of rasql.

Debugging directql

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 autotools to compile (deprecated):
    ./configure ...other options... --with-debug-symbols --with-optimization=0
    make
    make install
    # restart rasdaman
    
  • 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).
    

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 memory errors or 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. Reason is that writing an abundance of lines into log files slows down performance somewhat and further has a tendency to flood file systems - two reasons to enable it only if needed, not in production operation.

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

In case you are compiling with cmake (v3+), simply include -DENABLE_DEBUG. 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
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.