Contents

• Using Asserts
• IBM: Trace/BPT trap
• Quick-Turnaround Interactive Jobs on Klondike
• ARSC Fall Training Continues
• Butrovich Police Blotter
• Quick Tip

[ Thanks to Kate Hedstrom for this contribution ]

I recently gave a talk about debugging in which I spent a lot of time talking about how not to need a debugger in the first place. One such option for C/C++ programmers is the "assert" macro. If you know something that has to be true in your code, assert it.

assert is a function in the Standard C library and should therefore be available in any reasonable C implementation. Use it as:

#include <assert.h>

   assert(exp);

where exp is an integer expression. Any nonzero value will evaluate to true and your program will continue to execute. A value of zero will be read as false, leading to your program printing:

Assertion failed: Expression, file FileName, line LineNumber

and then calling abort. Note that abort will create a core dump of your program if your permissions, quota, and limits allow that to happen.

An example of using it would be checking to see if your constants are large enough:

#define MAX_COLORS 255
integer ncolors;

/* find out how many colors you really have... */

assert (MAX_COLORS >= ncolors);

It is possible to have your assertions checked during debugging, then not checked later for efficiency. By recompiling your code with NDEBUG defined, the checking will be turned off.

For the moderately adventurous, you can even read what's in /usr/include/assert.h to see how the assert macro is defined. For instance, on the IBM, NDEBUG turns off the checking through:

#ifdef NDEBUG
#define assert(ignore) ((void)0)
#else
   :
#endif

The else has a number of cases, depending on what version of C is being used. One is:

#define assert(__EX) ((__EX) ? ((void)0) : __assert(# __EX, __FILE__, __LINE__))

Here, __FILE__ and __LINE__ are special symbols that the C preprocessor will replace with the filename and the line number, respectively. __EX is the expression to be evaluated and the # operator before it is a "stringizing" operator, so that __assert can print the expression as a string rather than its value (which we know to be zero).

On the Cray and SGI, the man page points out: "Since assert is implemented as a macro, the expression may not contain any string literals." You also want to avoid such things as i++ in your expression since it will be evaluated twice if the assertion fails.

In summary, assert is a simple way to insert some checks into your code. If you don't want to pay a penalty for these checks, simply recompile with -DNDEBUG and they will be skipped.

When running code compiled with XL Fortran or XL C/C++, the error "Trace/BPT trap" or SIGTRAP can appear for a few different reasons. If you see this error it very likely that you asked for it. Most trap signals are enabled at compile time and are generated when a particular run-time problem is detected. If a trap signal is generated it's a good idea to track down the cause.

Below is an example "Trace/BPT trap" error from an MPI job.

iceberg 1% cat myjob.err
ERROR: 0031-250  task 0: Trace/BPT trap
ERROR: 0031-250  task 15: Terminated
...
...

According to the XLF User's Guide, trap signals can occur for several different reasons, below are the more common causes.

• Integer divide by zero.
• Out of bounds array subscript values when the -C compiler option is specified.
• Floating point exceptions when the corresponding suboption is enabled at compile time (i.e. -qflttrap)
• Floating point operations which generate NaN or loads of NaNs when the -qfloat=nanq compile option is specified.

See the XL Fortran User's Guide, reference " A " below for a complete list.

Similarly the following XLC compiler options can generate trap signals:

• Integer divide by zero when the compiler option -qcheck=divzero or -qcheck=all were specified at compile time.
• Out of bounds array subscript values for fixed and known sized arrays when the -qcheck=bounds or -qcheck=all compiler were specified.
• Floating point exceptions when the corresponding suboption is enabled at compile time (i.e. -qflttrap)
• When a signaling NaN is generated when converting from single to double precision at run time and the compiler options -qflttrap or -qflttrap=invalid and -qfloat=nans were specified at compile time.
• When a null address is detected and either the -qcheck=nullptr or -qcheck=all compile options were specified.

See the XL C/C++ Compiler Reference, reference " B " below for more details.

When a trap occurs a core file will be generated. If your application was compiled with debugging information a debugger can be used to determine where and why the trap was generated. For MPI code you may want to use lightweight core files to track down where the trap occurred.

For more information on traps and IBM lightweight core files see:

• IBM: Array Bound Checking:      /arsc/support/news/hpcnews/hpcnews314/index.xml#article3
• IBM XLF: Floating Point Exceptions and Traps:      /arsc/support/news/hpcnews/hpcnews313/index.xml#article3
• IBM Lightweight Core Files:      /arsc/support/news/hpcnews/hpcnews304/index.xml#article2

1. XL Fortran Enterprise Edition for AIX- User's Guide Version 9.1 (SC09-7898-00) p66

While the vast majority of jobs on klondike are scheduled through the PBS batch scheduler, ARSC also permits interactive work. Interactive jobs are those run through a terminal login session. All users have interactive limits of 12 MSPs (48 SSPs) and 15 minutes of MPP time.

Three nodes (12 MSP processors) are reserved from 8am - 5pm Alaska Time, Monday-Friday, for interactive work, and 1 node is reserved otherwise. Looking at this arrangement from the batch-user's point of view, PBS batch jobs are given access to 112 MSPs during work hours, and 120 MPSs, otherwise.

The goal is to provide better turn-around time and to enable interactive Totalview debugging sessions for users in the code development stage of work.

For a longer description of interactive processing on klondike, users may read "news interactive_jobs."

ARSC is offering more training opportunities in October and November in conjunction with Physics 693.

The following training is available over the next month. All ARSC users are invited. Classes are held in the West Ridge Research Building on Tuesday and Thursday from 9:15 - 11:15AM. All classes are in (WRRB) Room 009 except where noted in the schedule below.

For a complete schedule visit the Core Skills class website at:

Here's the latest alert posted to all Butrovich Building staff. It was sent mid-day, on October 6th. SW HR is the University of Alaska Statewide System Human Resources department.

> It has been reported to SW HR that a squirrel (yes, a squirrel) was 
> reportedly seen inside a mint green Mercedes in the Butro parking 
> lot... you left your sunroof open...

A: [[ Here are two lines extracted from a C program (could just as 
   [[ easily be a Fortran example):
   [[ -------------------------------------------------------
   [[     n = VALUE_OF_N;
   [[ #ifdef VERBOSE
   [[ -------------------------------------------------------
   [[
   [[
   [[ Here's a two line makefile to compile the program: 
   [[ -------------------------------------------------------
   [[ prog:
   [[        cc -D VALUE_OF_N=$(NNN) -D VERBOSE prog.c
   [[ -------------------------------------------------------
   [[
   [[
   [[ Here's how you could "make" this, specifying the ultimate value of
   [[ "VALUE_OF_N" (and thus, of "n" as well) on the command line:
   [[ -------------------------------------------------------
   [[ $   make NNN=1000
   [[ -------------------------------------------------------
   [[
   [[
   [[ And, finally, here's my question.  Is there a way to define or
   [[ undefine the macro "VERBOSE" (which takes no value) from the make
   [[ command line?  I want something like the following, which I know 
   [[ is incorrect:
   [[
   [[ $   make NNN=1000 -D VERBOSE 
   [[

#
# Thanks to Kate Hedstrom for this response.
#

The simplest solution in this case is to have no makefile at all, but
depend on the built-in make rules:

cygnus 1109% make CPPFLAGS="-D VERBOSE -D VALUE_OF_N=77" prog
cc  -D VERBOSE -D VALUE_OF_N=77   prog.c   -o prog

I couldn't figure out how to get the extra level of indirection here,
but it isn't necessary:

cygnus 1108% make CPPFLAGS="-D VERBOSE -D VALUE_OF_N=$(NNN)" NNN=1000 prog
Illegal variable name.

CPPFLAGS is a built-in make variable. If you have a Makefile, you could
explicitly refer to in the link statement:

cygnus 120% more Makefile.test
prog:
        cc -D VALUE_OF_N=$(NNN) $(CPPFLAGS) -o prog prog.c
cygnus 121% make -f Makefile.test NNN=42 CPPFLAGS=-DVERBOSE
cc -D VALUE_OF_N=42 -DVERBOSE -o prog prog.c



Q: My program produces output in NetCDF format.  Are there any 
   utilities available that will let me visualize my NetCDF data?  

[[ Answers, Questions, and Tips Graciously Accepted ]]

Ed Kornkven	ARSC HPC Specialist	ph: 907-450-8669
Kate Hedstrom	ARSC Oceanographic Specialist	ph: 907-450-8678
Arctic Region Supercomputing Center
University of Alaska Fairbanks
PO Box 756020
Fairbanks AK 99775-6020

Subscribe to (or unsubscribe from) the e-mail edition of the ARSC HPC Users' Newsletter.

Back issues of the ASCII e-mail edition of the ARSC T3D/T3E/HPC Users' Newsletter are available by request. Please contact the editors.