Getting Started with the Allinea Forge Debugger and Profiler

Request access to the wiki by sending an email to .

Allinea Forge is a commercially-available gui frontend to the gdb debugging tool:

and a profiling tool:

We are moving to this debugger at Fermilab as the license is less expensive than the TotalView license.

On the interactive dunegpvm machines at Fermilab, it is available as a pre-installed ups product. As of this writing, there is only one version, but no default version, so you have to specify the version on the setup line.

ups list -aK+ allinea
setup allinea <version>

If you need to install Allinea forge on a computer that doesn't yet have it using upd, follow the instructions here:

The debugger is called ddt, and it has simple built-in help for starting it

ddt --help

in addition to the web manual (links in here for both ddt and map)


I found that starting it with -nompi works to get started if I get this error message,

Allinea DDT detected you are using MPI, but could not detect which implementation.

There are a few things in art that are multi-threaded, such as the messaging system and interaction
with the SQLite database when running time or memory profiling services, though your program should be able to run single-threaded as well. Feel free to experiment with it.

You will have to specify the full path name to the executable, and arguments can be specified on the command line. For example, starting a (somewhat old) instance of lar, I used this command line (after typing "which lar" to find out the full path to the lar command for the version I had set up):

ddt --nompi /grid/fermiapp/products/larsoft/art/v1_17_07/ -c prodsingle_dune35t.fcl

or just

ddt --nompi `which lar` -c prodsingle_dune35t.fcl

Source code is also tricky to get DDT to find. Right-clicking in the Project Files window lets you add source directories. Subdirectories are searched for appropriate source, but you need to specify a full path including unique versions to get the source you want. The path to the source that was used to compile the program is stored along with the debug symbols, and Allinea checks to see if the source version matches that in the executable and shared libraries. Due to our installation procedure, this check will fail, and it is up to you to make sure that your source and executable match.

The output of the job goes to a window at the bottom selectable with the tab Input/Output.

Default Breakpoints

On the Control drop-down menu, there is an item "Default Breakpoints". These are quite handy if you want to debug exceptions that are thrown and caught (often segfaults aren't which is a good use for a debugger, but sometimes they are handled and you still want to debug them). Enable the checkmarks "Stop on throw (C++ exceptions)" and "Stop on catch (C++ exceptions)" to see these in the debugger. Warning though: some C++ exceptions are "normal"; especially in some external products, exceptions are used as part of the intended program flow. We discourage using exceptions unless something is wrong, otherwise finding one in the midst of many non-bad exceptions can be difficult.

TotalView Tips

As of Summer 2016, we no longer have a TotalView license. These tips are kept for reference (some may be useful in using our current debuggers).

A nice reference wiki describing how to use the TotalView debugger is available in the old larsoft SVN wiki with some tips, such as how to set breakpoints on exceptions:

and a shorter version on the new LArSoft page:

Setting breakpoints on exceptions:

Looks in the Control drop-down menu, and navigate to the "Default Breakpoints" menu item.  It has checkboxes for
setting breakpoints on C++ exception throwing and catching.

Old list of symbols used for setting breakpoints in TotalView (not yet tested in Allinea)