You are here: NRAO Public Wiki>Software Web>LegacyCASA>ObtainingCASA>CasaIndex>RunningDebuggers (2011-03-20, RobReid) Edit wiki text Edit Attach Print version

Running a debugger with casapy or casacore

casapy

Start casapy as usual, and take it to just before where you think things start to go awry.
Attach to the casapy process using your debugger. I recommend ddd, a GUI for gdb. nemiver is also good. It has some convenient improvements over ddd, but seems to be less flexible in what data it can display. Make sure you attach to the right casapy process (usually the first one of a pair), and not ipengine or ipcontroller (unless you really want to, of course). If you got it right, the casapy session will freeze, waiting for a debugger command like "step" or "cont".
If using ddd click on Open Source. You will probably have to "Load Shared Library Symbols" in the popup window. Eventually a long list of files will appear, which can be filtered by typing what you want in the top box. i.e. Typing "SubMS" in the top box will restrict the bottom one to SubMS.cc and SubMS.h, which you can then click on to select. Because the whole list is so long, and ddd is only so smart, resist the temptation to complete a class instance with xxx.. It will take a long time and not help you anyway.

How to handle "ptrace: Operation not permitted"

Attaching to a process is a potential security problem, so starting with 10.10 Ubuntu has defaulted to disallowing it. See https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#ptrace for more details. "gdb program_x" still works, but attaching to a running program_x will not. Other distibutions will probably follow, but for now the solutions here are Meerkat-specific. Pick one of the following:

(Recommended)

sudo sh -c "echo 0 > /proc/sys/kernel/yama/ptrace_scope"

This will turn off ptrace protection for the whole computer. When done debugging (or even right after attaching?), turn it back on with

sudo sh -c "echo 1 > /proc/sys/kernel/yama/ptrace_scope"

or rebooting.

Run the debugger as root.
Disable the protection until further notice by tweaking /etc and sysctl.
(Untried) Try restarting casapy from within ddd (Kumar's suggested solution for a different problem).
Get casapy to grant permission for the pid of the debugger to attach. Let me know if you get this to work!

casacore

If you got to casacore using the above process through an interactive program like casapy, fine. Otherwise you have to get the debugger to start up your program itself, with the right environment. If your shell's startup scripts distinguish between interactive and noninteractive sessions, this is a little tricky since normally the CASA environment belongs on the interactive side, but gdb (ddd) starts processes in a noninteractive shell. To make life easier, put your CASA startup stuff in its own file, e.g. ~/.sh_casa. Here's mine:

# Setup the environment for compiling CASA. # This is hardwired for *(?).cv or basho(?).aoc - nothing will happen on # other computers, on which the appropriate casainit.sh will have be sourced # before compiling CASA. if [ -d /export/data_1/casa ] ; then export xpot=/export export d1=$xpot/data_1 export d2=$xpot/data_2 export CASAROOT=/export/data_1/casa/gnuactive elif [ -d /net/faraday/export/data_1/casa ] ; then export xpot=/net/faraday/export export d1=$xpot/data_1 export d2=$xpot/data_2 if [ "$HOSTNAME" = "protostar" ] ; then export CASAROOT=/export/data_1/rreid/casa else export CASAROOT=$d1/casa/gnuactive fi #elif [ -d /home/basho3/rreid ] ; then # export CASAROOT=/home/basho3/rreid fi myarch=$(uname -i 2&gt;& /dev/null) case "$myarch" in "i386") export CASAARCH=$CASAROOT/linux_gnu ;; "x86_64") export CASAARCH=$CASAROOT/linux_64b ;; *) echo "Warning: $myarch (from uname -i) is an unrecognized architecture." echo "\$CASAARCH has been left unset." esac export CASADATA=$CASAROOT/data if [ -f $CASAROOT/casainit.sh ] ; then [ x$ZSH_VERSION = x ] || emulate sh . $CASAROOT/casainit.sh [ x$ZSH_VERSION = x ] || emulate zsh fi

# This is for checking in, not compiling. if [ -f $CASAROOT/code/xmlcasa/install/setsvneditor.sh ] ; then . $CASAROOT/code/xmlcasa/install/setsvneditor.sh fi

# For ddd of casacore unit tests. if [ "$MUST_LOAD_CASA" = "dcct" ] ; then export LD_LIBRARY_PATH=$CASAARCH/lib:$LD_LIBRARY_PATH fi

# Helper function for caxml2py() _saxify() { # Expects $casadev, $taskname, name of xsl file relative to # $casadev/install. local casadev="$1" # Quoted in case of spaces. local taskname=$2 local xsl="$3"

local ci="$casadev/install"

java -jar "$ci/saxon8.jar" "$casadev/tasks/${taskname}.xml" "$ci/$xsl" }

# Adapted from somthing Remy Indebetouw sent. # Expects $taskname. caxml2py() { local casadev="$CASAROOT/code/xmlcasa" local destdir=$(\ls -d1 $CASAARCH/python/*.*) local dest="$destdir/$1"

_saxify $casadev $1 casa2py.xsl &gt; "$dest".py _saxify $casadev $1 casa2pycli.xsl &gt; "$dest"_cli.py _saxify $casadev $1 casa2pyimp.xsl &gt;&gt; "$dest".py }

# This is how to compile a simple program which depends on casacore but is not # part of it. make_casacore_app() { declare -a includes declare -a libs for i in images casa fits components coordinates lattices measures ms msfits scimath tables; do includes+="-I$CASAROOT/casacore/$i" libs+="-lcasa_$i" done g++ ${includes[@]} -I. -I/usr/include/cfitsio -o ${1:r} $1 -L$CASAARCH/lib ${libs[@]} -lcasa_measures_f -lcasa_scimath_f -lcfitsio -lcasa_mirlib -lwcs -llapack -lblas -lcfitsio -ldl }

# Announce completion. export MUST_LOAD_CASA="no"

If your setup is anything like mine, noninteractive customization is done first for all sessions, whether or not they are interactive. If the session is interactive, ~/.zlogin is then read. So one solution would be to source ~/.sh_casa in your noninteractive startup script. That would be wrong, though, since it would be sourced by all noninteractive shells. The least that would happen is CASA version numbers being printed at weird times and places. So set up your startup scripts to source your ~/.sh_casa once in either your interactive (default) or noninteractive startup scripts. I use zsh, but call my noninteractive startup file ~/.sh_generic because it can also be used by bash. Here's the relevant stanza from my ~/.zlogin (linked to ~/.profile), from near the end:

if [ "$MUST_LOAD_CASA" != "no" ] ; then . $HOME/.sh_casa fi

~/.sh_generic gets this at its end:

if [ "$MUST_LOAD_CASA" = "y" ] ; then . /users/rreid/.sh_casa fi

Thus can I develop in CASA while keeping most of the noninteractive sessions blissfully ignorant of it. ddd is the exception, and it gets started a la

MUST_LOAD_CASA=dcct ddd tArrayOpsDiffShapes

What to do if ddd sees the .h file, but not the .cc file:

Load the .h file.
Explicitly load the .cc file with the "list" command, i.e. if you want to look in MSFitsInput.cc, and after loading MSFitsInput.h the ddd window's title bar says "msfits/msfits/MSFits/MSFitsInput.h", type

list msfits/msfits/MSFits/MSFitsInput.cc:1778

(assuming you want line 1778) Note that the path should be given in the same way as ddd presents for the .h file. This is especially important for casacore files. Also, it works better if you specify the line number.

valgrind

valgrind is a different sort of debugger, specialized for finding potential segfaults, memory leaks, and uses of uninitialized variables.

Pros:

It can be made to start gdb when it finds an error (--db-attach), which is great when the error only happens on the nth iteration of a loop, where n is a random large number.

Cons:

It's slow.
If you just run valgrind casapy, you will get ~30000 errors from casapy's Python<->C++ interface. I think this is because of the way Python handles garbage collection. It does not seem to add up to much over a session. I strongly recommend you use a suppressions file (see below) to cut out irrelevant error reports.
--trace-children=yes can set off a forkbomb! It seemed to frequently start and kill casaviewer processes. I was able to recover by running top and killing the top 2 or so processes (memcheck...).

Example:

valgrind --suppressions=/absolute/path/to/valgrind.suppressions --gen-suppressions=yes --db-attach=yes casapy

--gen-suppressions is the easiest way of adding to valgrind.suppressions, but if you already have enough suppressions hit c to make it stop asking you if you want another suppression. Note that the prompts are case insensitive.

-- RobReid - 2010-10-13

Topic attachments
I	Attachment	Action	Size	Date	Who	Comment
suppressions	valgrind.suppressions	manage	4 K	2011-03-20 - 16:41	UnknownUser	A suppressions file for valgrind that cuts out the ones from the Python interface (the vast majority of them) plus a few more specific casapy errors that always happen during startup or exit. The latter don't concern me, but they might concern you! (version that also works with 64bits and/or Ubuntu)

Topic revision: r3 - 2011-03-20, RobReid

Software

Copyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding NRAO Public Wiki? Send feedback