Debugging ASCEND

The content from this page was lost in a recent server failure. We will be working to restore this content as soon as possible.

Reporting a bug

There is a Bug tracker for ascend outside of this wiki.

Some useful additional information relating to debugging:

• about test suites (see CUnit)
• using Valgrind to track down segfaults and memory leaks

Also to be added here:

• about Buildbot (currently inactive/offline)
• using GDB
• correct use of SVN during debugging on the trunk
• using 'pygtk/ascdev' and 'tcltk/asc4dev' from within your working folder
• possible library wrong-loading issues: export LD_LIBRARY_PATH=~/ascend for example,

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. ” (Brian Kernighan)

Using GDB

ASCEND loads its solvers from shared libraries using dlopen. This sometimes causes difficulties with libpthread.so when using gdb for debugging. A solution that sometimes works is along these lines (the exact file location may depend on your Linux distro) is given here. For example:

cd ~/ascend
scons -j4 DEBUG=1 test
export MYASCEND=`pwd` && export ASCENDSOLVERS=$MYASCEND/solvers/ida:$MYASCEND/solvers/ipopt:$MYASCEND/solvers/lsode:$MYASCEND/solvers/qrslv:$MYASCEND/solvers/lrslv && export ASCENDLIBRARY=$MYASCEND/models && export ^C_LIBRARY_PATH=$MYASCEND
LD_PRELOAD="/lib/i386-linux-gnu/libpthread.so.0" gdb --args test/test integrator_idaevent.test1