Quick facts

Add-on Modules:


Technical Papers

Support & Manuals


Recent Reviews

User Testimonials

Press Releases

Insure tool to debug c++

Frequently Asked Questions

Revision 5.1, last updated: May 5, 2000

Please see also the new searchable, on-line support database.

Section 1 Introduction

Section 2 Configuration

Section 3 Insure

Section 4 Inuse

Section 5 TCA (Coverage Analysis)

Section 1 Introduction

1.1 Contacting ParaSoft

If the information in this section is insufficient to correct your problem, please follow the procedure outlined below when contacting technical support.

  • Check the manual

  • Attempt to isolate a suspected bug to a trivial example. A good method is to comment out half of the code and try compiling again, repeating the process until the problem is isolated to ten or twenty lines. Often this procedure can suggest a fix or work-around.

  • If the problem is not urgent, report it by e-mail to
    or by fax to
        (626) 305-9048
  • Before calling support at
        (626) 305-0041 
    know your Insure++ version. You can easily find it by typing
    with no arguments.

  • Know your operating system and compiler versions. You can get the OS version by typing
        uname -a
  • Please use a phone within reach of your computer. The support technician may need you to try things while you are on the phone.
  • Be prepared to recreate your problem.
  • Please be patient.

Section 2 Configuration

  • 2.1 The INSIGHT/PARASOFT environment variables

    Versions of Insure++ earlier than 2.1 required that an environment variable called INSIGHT be set to the Insure installation directory. Versions beginning with 2.1 and more recent versions require only that the bin.$ARCH directory be on your path.

    Versions of Insure++ starting with 3.1 added the PARASOFT environment variable. The only difference between the two variables is that INSIGHT is used only by Insure++, while PARASOFT is used by all ParaSoft tools. They both perform the same function.

    If you find it useful to set the variable, remember that it will be used by Insure++, so it must be set correctly (see section 2.2.1).

2.2 Licenses

  • 2.2.1 Installing a license
    A typical Insure++ license for a SunOS network looks like:
    Tool               : Insure++ 5.1
    "iihostid" value   : SUN4++-80000000
    Date of expiration : 7777777 (Jan 1, 2001)
    Password           : 1575b2235ef96b76-3203 (1 user)
    • Make sure that the bin.$(ARCH) directory is on your path
    • If you have the INSIGHT or PARASOFT environment variables set, make sure they are set correctly:
      • execute "echo $INSIGHT" or "echo $PARASOFT"
        • they should be set to the Insure installation directory
        • if the end is "/bin.sun4" (or similar for different platforms) it is set incorrectly
        • execute "ls $INSIGHT" or "ls $PARASOFT" - the output should look like:
    		-> ls $INSIGHT
    		bin.sun4/    examples/      help/       include/	
    		lib.sun4     man/           src.sun4/
        • (with the appropriate platform name(s), of course)
      • if you cannot get it set correctly, unset it completely by executing "unsetenv INSIGHT"
    • Make sure you have write permissions in the $INSIGHT directory - if not, become root (superuser)
    • Use pslic to install license for correct Insure version
    • After exiting and saving changes (option E in pslic), run pslic again and make sure the license is actually installed

  • 2.2.2 "You do not have a password"
    • Verify that you have a license installed for the machine on which Insure is being run
      • Execute "pslic" on the machine on which you want to use Insure
      • Run "pslic" to display the machine and/or network ids for the installed license
      • compare the machine and/or network ids
      • If they do not match, contact your ParaSoft account representative for a new license
    • If you have the INSIGHT or PARASOFT environment variable set, make sure they are set correctly (see section 2.2.1)
    • Make sure you have read permissions for the .psrc file in the Insure installation directory ($INSIGHT directory)
    • Does insure run from the command line but not from a makefile?

      Using an INSIGHT or PARASOFT variable in the makefile will define it as an environment variable generally, which tells Insure to look in the wrong place for the license file. You should use INS or something other than INSIGHT or PARASOFT for such a makefile variable

  • 2.2.3 "You have an incorrect password"
    • Look for an old/incorrect license
      • look in .psrc files in users' home directories, old Insure installation directories, etc.
      • the licenses in .psrc files look like:

        Insure++.Password 3.1 SUN4-80000000 6553601 8c05

      • You can simply delete any old licenses from the .psrc files
      • Make sure you don't delete the working license
  • 2.3 .psrc configuration files
    .psrc files can be used to specify various options to Insure, TCA and Inuse, and they are processed in a certain order. The order in which .psrc files are read and the scope of their effects are given below. An option will be overridden if the same option is found in a file lower in this list.
    Options in this file affect everything done with the compiler $COMPILER for all users.
    Options in this file affect everyone who uses Insure all of the time.
    Options in this file affect everything a particular user does with Insure.
    build_dir is the directory in which you are currently compiling. Options in this file affect everything compiled in this directory.
        -Zop filename
        -Zoi "option"

    These command line options allow additional .psrc options to be passed in a file (-Zop) or as a single option (-Zoi) on the insure command line. Any valid .psrc option can be placed in filename or passed as option. These command line options are processed from left to right before any source files are processed.

  • 2.4 Telling Insure which compiler to use
    If you normally use a compiler other than cc, you can tell Insure to do the same by adding, for example, the option
        insure++.compiler gcc 

    to your .psrc file (see section 2.3). This tells Insure to use gcc instead of cc every time Insure is called.

    If the compiler you use is not one that is directly supported by Insure, you will also need to use the compiler_acronym option (see section 2.5).

    If you use both C and C++ compilers in the same directory, you can use the options compiler_c, compiler_cpp, and compiler_default to specify the new default compilers for .c files, .C (.cc, .cpp, etc.) files, and .o files (i.e. linking), respectively.

    Insure's defaults for most platforms for these options are

        compiler_c cc
        compiler_cpp CC
        compiler_default c

    (For AIX, compiler_cpp is set to xlC, and for Digital UNIX, compiler_cpp is set to cxx.)

    In words, this means that cc will be used to compile .c files, CC will be used to compile .C (or .cc, .cpp, etc.) files, and cc will be used to link when only .o files are present on the command line.

    As an example, if you use gcc for compiling .c files, g++ for compiling .C (or .cc, .cpp, etc.) files, and the C++ compiler for linking, you would add the following options to your .psrc file.

        compiler_c gcc
        compiler_cpp g++
        compiler_default cpp
    The "compiler" and "compiler_acronym" options override these options and tell Insure to always use the compiler indicated, regardless of file extensions.

    Scripts can also be used to customize your Insure environment and make using different compilers more convenient. There are several examples in the examples/scripts subdirectory of the Insure distribution.

  • 2.5 Missing TQS interface files
    If you are switching between compilers or using a compiler that is not directly supported by the shipped version of Insure, you may see the following error message:
        Unable to find TQS interface files for compiler XXX.  
        Try adding one of the following lines to your 
        .psrc file AFTER the line setting the compiler
            compiler_acronym cc 
            compiler_acronym CC
            compiler_acronym gcc
            compiler_acronym g++

    This message is generated whenever you use a compiler for which TQS interface files have not been supplied with your system. If your compiler does not have its own interfaces, you need to use the compiler_acronym option, which tells Insure to use the interfaces supplied for one of the other compilers. The various libraries supplied with different compilers are normally compatible, so this will work correctly.

Section 3 Insure

3.1 Compiling

  • 3.1.1 C++ source in .c files

    By default, Insure treats all files with the .c extension as C code only. If you want to use C++ code in such files, you need to set the option

        insure++.c_as_cpp on
    in your .psrc file. See the User's Guide for more information about this option.

  • 3.1.2 Interface mismatch/ Conflict with interface definitions
    Insure is supplied with approximately 2,000 interfaces to common C and UNIX functions. There are two common problems that may arise when using these interfaces. The first is caused by reusing the name of one of these functions in your program to define a function which is different from the C/UNIX one that Insure knows about. This will result in an error during compilation describing the conflict. The second problem arises if the prototype for a standard function on your platform differs from that which Insure is expecting. This will also result in a compile-time error message from Insure. If you don't want to change your code to conform to the stricter definition to avoid portability problems, you will need to either turn off or modify the Insure interface.

    For example, you may have written a function called malloc. Since this is the name of one of the standard UNIX functions, Insure will check its arguments and return type against those of the system call. This typically results in a BAD_DECL error during compilation

        Actual declaration of malloc conflicts with interface.
    and many BAD_PARM error messages. You may also get a message like the following:
        ** Insure was unable to fully check the following routine 
        ** due to a serious mismatch between the interface declaration 
        ** and your program's declaration.  You can use the "iiwhich" 
        ** to examine the interface and resolve this conflict.  

    You can eliminate the conflict by placing a simple directive in a .psrc file. In this example, you would add the following line to your .psrc file in the current directory:

        insure++.interface_ignore malloc

    This tells Insure to ignore the interface definition. (Alternately, you may want to create your own interface to this function, as explained in the "Interfaces" section of the Insure++ User's Guide).

    If you need to modify an Insure interface to avoid problem 2 above, here are the necessary steps:

    Identifying the file to modify:
    • 1. Go to the $PARASOFT/src.$ARCH/$COMPILER directory.
    • 2. Find files which have "problem" symbols in them. (e.g. grep "symbol" *.c)

    Fixing the interfaces:

    • 3. Edit the files with "problem" symbols and change or remove all references to the "problem" symbols.

    • 4. For each file, do:
      iic foo.c (creates a file foo.tqs)

    • 5. Copy each tqs file to $PARASOFT/lib.$ARCH/$COMPILER.

    • 6. Add to $PARASOFT/lib.$ARCH/$COMPILER/.psrc:
      insure++.interface_library foo.tqs (for each tqs file)

    • 7. Recompile and Test

      If you do not have write permissions to do the above, skip Step 5 and change Step 6 to:

    • 6. (Alternate) Add to user's home .psrc file:
      insure++. interface_library /full/path/foo.tqs (for each tqs file)
  • 3.1.3 Old-style prototypes
    Insure supports both K&R and ANSI styles of programming. Difficulties arise in only one case:
        typedef struct list { 
            int a,b; 
        } list;
        void func1(list) 
            int list; 
    ANSI C doesn't allow an argument variable to have the same name as a defined type, such as list in this example.

  • 3.1.4 Variable size (stretchy) arrays
    Many programmers build structures in which the last element is an array whose size is only determined at runtime. For example:
        struct stretchy {
            int nvals;
            int data[1];
    In versions of Insure++ earlier than 3.1, the way to deal with this was to add the option
        insure++.expand struct 
    to your .psrc file. Insure++ 3.1 automatically detects stretchy arrays and handles them appropriately. This new ability is controlled by the "auto_expand" .psrc option. See the User's Guide for more information.

  • 3.1.5 BAD_DECL errors
    Some users have been confused by this error when it indicates a common problem. Consider the following code:

                char *ptr = malloc(10);
                return 0;
    The problem, which is somewhat obvious here in a tiny code fragment, is that the programmer has forgotten to include the header file which contains the prototype for malloc. When the above code is compiled with Insure, you will see the following output:

        insure -g -o foo foo.c
        [foo.c:3] **BAD_DECL**
          Declaration of function malloc conflicts with library interface.
          Actual   return type: malloc_t
          Declared return type: int at foo.c, 3
        >>     char *ptr = malloc(10);

    To eliminate the error, all you need to do is include stdlib.h in the code above and recompile.

3.2 Linking

  • 3.2.1 Unresolved _Insight_* symbols
    If you are using libraries built from objects which were compiled with Insure, you must link with either the insure command or in special circumstances ins_ld. A failure to do so will result in undefined _Insight symbols.

  • 3.2.2 Separate linking fails
    If you compile your code and then separately link the objects, i.e.
        insure -c
        insure -o foo foo.o
    you need to tell Insure what type of linking to use, C or C++. Insure cannot tell from a .o file which linking to use, so C linking is used by default. You can tell Insure to use C++ linking by adding the line:
        insure++.compiler_default cpp
    to your .psrc file. This option tells Insure to use the default C++ compiler to link, which you can set using the compiler_cpp option (see section 2.3).

  • 3.2.3 Using your own malloc library
    By default, Insure replaces the standard memory routines with its own, which are optimized for additional memory checking. If you use your own malloc library, you need to tell Insure not to replace your library. You can do this by adding the following line to your .psrc file and relinking.
        insure++.malloc_replace off
    See the User's Guide for more information about this option.

  • 3.2.4 Using templates with cfront compilers

    This section is _not_ necessary for the following platforms and compilers:

    • DEC Alpha - cxx
    • SGI IRIX - CC, DCC, NCC, etc.
    • Sun Solaris 1.X/SunOS 4.1.X - CC
    • Sun Solaris 2.X/SunOS 5.X - CC
    Insure handles templates for the above platforms in a different way, which should prevent any linking problems related to templates. If you have any problems linking with templates on the above platforms, please contact ParaSoft technical support.

    For other platforms and compilers, the following suggestions may prove helpful in solving problems with undefined template symbols.

    There is a problem in the way that Insure and cfront compilers interact when handling templates. Cfront compilers create subdirectories for template instantiation objects, which attempt to reference static temporary variables that Insure creates in your source files. The object files that result from your source files are renamed, which confuses the template manager when it tries to find the static variables in the template objects. This results in undefined symbols at link time. The solution to this problem is two-pronged.

    First, you need to set the following options in your .psrc file:

        insure++.rename_files on 
        insure++.compiler_deficient no_static_temps 
    This makes the temporary variables that Insure creates non-static and tells Insure to compile the instrumented source code in the original file names. See the User's Guide for more information on these options. The second (platform-dependent) remedy is to add the following to your link line:
        ptrepository/*.o	(HP-UX)
    This links in the template objects that the template manager creates in the template subdirectory of your working directory. This should solve the problem.

  • 3.2.5 Calling the linker explicitly - ins_ld
    If you are linking your program explicitly with ld, you should use the ins_ld command. If you normally call the compiler to link your program, you should use the insure command.

    To use ins_ld, replace ld with ins_ld in your makefile. If you use a linker other than ld, add the following option to your .psrc file

        insure++.linker linkername

    where linkername is the name of your linker, e.g. my_ld.

  • 3.2.6 Multiply-defined stdlib functions
    By default, Insure links in its own versions of several stdlib functions, e.g. strcmp, strcpy, and strtok. These versions have additional checking built in which helps Insure detect errors in third-party (not compiled with Insure) code. These functions may collide with those in libc.a, resulting in multiply-defined symbols, which will cause the link to fail on some platforms. This problem can be solved by adding the option
        insure++.stdlib_replace off

    to your .psrc file and relinking your program with Insure. Since these functions are not used to detect errors in code that was compiled with Insure (interfaces are), you will not notice any difference in error detection if you are compiling all of your code with Insure.

  • 3.2.7 Building shared libraries
    Shared libraries can be built with Insure-compiled objects, but the exact commands vary widely across platforms. Here are the necessary steps for several supported platforms. If your platform does not yet appear, try to modify one of the given methods for your situation.

    The commands are given in the context of a shared library containing one object, which is built from the source file foo.C. The file main.C contains the function main, which calls a function in foo.C. In each example, the first command shows how you should compile any objects which will end up in the shared library, the second shows how you should build the shared library, and the third shows how you should build the final executable.

    • DEC Alpha OSF/1 (Digital UNIX)

          insure -g -c foo.C
          ins_ld -shared -o foo.o
          insure -g -o foo main.C
    • HP HP-UX

          insure -g +z -c foo.C
          ins_ld -b -o foo.o
          insure -g -o foo main.C  -L. -lfoo
    • SGI IRIX 5.X

          insure -g -c foo.C
          ins_ld -shared -o foo.o
          insure -g -o foo main.C
    • Sun Solaris 5.X

          insure -G -KPIC -g -c foo.C
          CC -G -Bdynamic -o foo.o
          insure -g -o foo main.c
    • Sun SunOS 4.1.X

          insure -g -c foo.C
          ld -Bdynamic -o foo.o
          insure -g -o main.C
  • 3.2.8 Linking with -Zuse

    The -Zuse command line option tells Insure to build your program for use with Inuse. This means that all error detection is turned off. A -Zuse on a compile line tells Insure to pass the file straight to the compiler without instrumentation, while a -Zuse on the link line tells Insure to link in only the libraries needed for Inuse. This can result in undefined _Insight symbols if you compile some files with Insure and link with Insure and the -Zuse option.

    The correct way to build your program for use with Inuse is to compile your source without Insure (or with Insure and -Zuse, which is really the same thing) and link with Insure and -Zuse. You will then see only your program's memory usage, and not Insure's. Of course, you may use Inuse after compiling and linking normally with Insure to do error checking, but you will also see Insure's memory usage as it does error detection.

3.3 Running

  • 3.3.1 "Unable to read symbol table"
    This error message is normally of the form:
        Unable to read symbol table:  
                    cannot find executable
        You should either:  
            1) set the .psrc option "insure++.symbol_table off" 
            2) set the .psrc option "!insure++.exename name", 
                    where name is the full path
                    and name of this program

    The problem is that Insure needs to be able to find and read your executable in order to read its symbol table. If this doesn't happen, your stack traces will be filled with
    "pc = 0x0000246c()" instead of function names (pc stands for program counter, and indicates where your functions lie in memory).

    As indicated in the error message, there are two options for resolving this problem. The " symbol_table off" option switches to an alternate stack tracing mechanism which is slightly faster, but will not be able to show functions which have not been compiled with Insure (see section 3.3.2). To get full stack traces with filenames and line numbers with "symbol_table off", you will also need to recompile your source code with Insure with the option

        insure++.stack_internal on
    in your .psrc file.

    The best solution is to set the exename option in your .psrc file to specify the full path and name of the executable, e.g.

        !insure++.exename /home/elephant2/bin/test
    The ! is necessary to override the "compiled-in" executable name that Insure included in the program at compile time. See the User's Guide for more information about this option.

  • 3.3.2 Stack trace message "routine not compiled with insure"
    This message is only seen if the option "symbol_table off" is being used (see section 3.3.1). In this case, if you process only some files with Insure, e.g. use third-party libraries, you may see stack traces which have missing routines. In particular, if execution goes from code processed with Insure to code not processed and then back again, the stack traces will be missing the routines from the un-processed files and will have "routine not compiled with Insure" in their place.

  • 3.3.3 Using interactive debuggers

    Programs built with Insure can still be run under interactive debuggers like dbx and gdb. This is often a powerful combination which makes finding and fixing bugs a much easier task. The following sections describe several considerations when using interactive debuggers with Insure.

    • Stopping when Insure reports an error
      A very common question is how to tell an interactive debugger to stop whenever Insure reports an error in your code. This can be done by setting a breakpoint on the function _Insure_trap_error.

      If you are linking against the Insure libraries dynamically (the default), you may not be able to break on _Insure_trap_error before starting the program. This is because shared libraries may not be loaded until the program begins execution. In order to break on _Insure_trap_error, you can either

      • link against the Insure libraries statically by adding the option
            insure++.static_linking on

        to your .psrc file and relinking with Insure


      • break on main and start the program running before adding the breakpoint on _Insure_trap_error, i.e.
        -> gdb foo
        (gdb) b _Insure_trap_error
        Function "_Insure_trap_error" not defined.
        (gdb) b main
        Breakpoint 1 at 0x237c: file foo.c, line 9.
        (gdb) run
        Starting program: /usr/local/bin/foo 
        Breakpoint 1, main (_Insight_argc=1, 
            ;_Insight_argv=0xeffff874) at foo.c:9
        9       {
        (gdb) b _Insure_trap_error
        Breakpoint 2 at 0xef78383c: file trap.c, line 74.
        (gdb) c
    • "warning: can't find 'foo_1000.c'"
      Normally, Insure creates an intermediate file containing the instrumented version of the original source code, which is passed to the compiler. In some cases, this may confuse debuggers. With dbx, for example, you may see messages like:
          warning: can't find 'foo_1000.c'
          warning: can't find 'NoName'
      If this is the case, you should add the option
          insure++.rename_files on

      to your .psrc file and recompile your program.

      This tells Insure to instrument and compile the file in the original file name and then restore the original source to foo.c. An original source file called foo.c would be renamed foo.c.ins_orig for the duration of the call to Insure.

      Only use this option if you are having problems with your interactive debugger.

  • 3.3.4 Errors in scanning variable length arguments aren't detected
    This is a limitation of the current release of Insure. Type checking is not performed on arguments retrieved using the va_arg function, for example:
        #include <varargs.h> 
        main() { 
            int i,j,k; 
            i=2; j=5;
            k = func(i,j); 
            printf("k = %d\n",k); 
        int func(va_alist) 
            int j,k,i; 
            va_list ap; 

  • 3.3.5 Errors referencing bit-fields
    When you dereference a structure, Insure checks that memory is being used properly. However, due to the machine and compiler dependent nature of bit fields, Insure is unable to check these exactly. Instead, the size of the entire structure is checked. In case of failure, a message is issued.

  • 3.3.6 "c++filt: Not found"
    On some platforms, Insure uses the external demangler provided by the C++ compiler vendor (c++filt) to demangle C++ function names. This is specified in the compiler default .psrc file (lib.$ARCH/$COMPILER/.psrc) using the option
        insure++.demangle_method filter c++filt
    This option tells Insure to call the program c++filt whenever it needs to demangle a C++ function name for printing a stack trace. This will work fine as long as c++filt is on your path. If it is not, you may see errors similar to:
        /usr/local/insure/bin.riscy/ins_filt: c++filt: Not found
    when you run your program.

    There are several ways to solve this problem:

    • Add the location of c++filt to your path.

    • Make a link from c++filt to a directory already on your path, e.g.
          cd /usr/local/bin
          ln -s /usr/lpp/xlC/c++filt .
      if /usr/local/bin is on your path and c++filt is located in /usr/lpp/xlC.

    • Add the path to c++filt to the demangle_method option by adding the option
          !insure++.demangle_method filter /usr/bin/c++filt
      to your .psrc file. The ! before demangle_method is necessary to override the setting that was compiled into your program. See the section on compiled-in options in the Insure++ User's Guide for more on this issue.

    • Turn off demangling by adding the option
          insure++.demangle off

      to your .psrc file.

  • 3.3.7 "Missing" LEAK_SCOPE in main
    This section addresses a common confusion among Insure users. Insure does not report what would be a LEAK_SCOPE error when it occurs in the function main. To illustrate why, I will use the following simple example.
        #include <stdlib.h>
        main() {
            char *ptr = malloc(10);
            return (0);
    This may look like a memory leak, but it really is not. The pointer ptr points to the block of memory allocated by the call to malloc until the program leaves the function's scope. However, at that point, the program has terminated and the memory is freed by the OS. There is never a point during program execution where there is not a valid pointer to the block, which would allow it to be freed. Since there is always a valid pointer to the block of memory while the program is running, it is not leaked. This is classified by Insure as an outstanding allocated memory block. If you are interested in seeing such blocks reported, you can simply add the option
        insure++.summarize detailed outstanding
    to your .psrc file and run your program again. Insure will then print a report of all outstanding memory blocks with allocation stack traces.

3.4 Platform specifics

3.4.1 DEC Alpha (Digital UNIX)

  • Old cxx compiler does not process #if 0/#endif correctly
    Versions of the DEC cxx compiler for Alpha older than 5.0 do not process #if 0 and #endif directives properly. This causes Insure to report incorrect line numbers and lines of code in error messages. The given lines are displaced from the actual lines by an amount equal to the number of lines between the #if and #endif directives.

    Some users have continued to experience this problem with cxx 5.X when their LANG environment variable has been set to something other than C. Resetting LANG to C, e.g.

        setenv LANG C

    solves the problem.

3.4.3 HP9000 (HP-UX)

  • Using SoftBench
    Insure can be used from within the SoftBench environment by specifying "Build Options" to SoftBench's Program Builder tool. Compiling with Insure involves the following steps:
    • Defining the CC variable in your makefile to the name of the compiler normally used.
    • Adding the line CC=insure to the "Build Options" (see Figure 1). (Figure 1 only available in postscript document).
    • Selecting "Build Target" from the Program Builder Actions menu.
    After the program is successfully built using Insure, the target program can be tested by selecting "Run Target" from the Actions menu in the Program Builder tool. The following makefile gives an example of using the CC variable to assign the default compiler. In this case, the cc compiler is used.
        sample1:  sample1.c
            $(CC) -o sample1 sample1.c
    This will build sample1 using:
            cc -o sample1 sample1.c
    When specifying CC=insure in the "Build Options", sample1 is built using:
            insure -o sample1 sample1.c
    Any number of options may also be specified when defining the CC variable in the "Build Options" entry window. For example, the definition of CC="insure -Zvm -Zpr" in the "Build Options" entry window says to build the objects using Insure, and pass the verbose flag and the profile flag.

  • Using the -H cpp option correctly
    If you have a long line in your source file, you may see an error message from cpp saying something like:
        ``Concatenated input line too long''
        ``Macro buffer too small''

    The error message will tell you to use the -Hnnn option to solve the problem. If you try to pass the -Hnnn option on the command line, it will be passed to the compiler, which will complain. In order to have the option passed to cpp, you need to use -Wp, -Hnnn on the command line. This will solve the original problem.

    If you are using the ANSI preprocessor (cpp.ansi), there is another wrinkle to using the -H option. Although the error message mentions the -H option, cpp.ansi does not recognize it. With cpp.ansi, you need to use the -B option.

    For more information about the -H option itself, please see the cpp man pages.

3.4.4 IBM RS/6000 (AIX)

  • FUNC_BAD is off for AIX 4.1.X
    The error category FUNC_BAD is disabled for the AIX 4.1.X version of Insure. AIX uses an address in the data segment as a function in iostream.h, which was causing Insure to print incorrect error messages for code in that header file.

  • Undefined __strnc* symbols
    On some RS/6000 systems, the symbols __strncpy, __strncmp, and/or __strncat will be reported at link time as undefined symbols, even though you are not calling these functions directly. The solution is to make dummies for these functions and link them into your program. The dummies should look like:
        int __strncat(char *s1, char *s2, int indx)
            return(strncat(s1, s2, indx));
        int __strncmp(char *s1, char *s2, int indx)
            return(strncmp(s1, s2, indx));
        int __strncpy(char *s1, char *s2, int indx)
            return(strncpy(s1, s2, indx));

3.4.7 Sun Sparc (SunOS 4.x, Solaris 1.x)

  • Using an older CC
    Insure's default configuration is for CC 4.0.1. If you are using an older version of the compiler, you need to use slightly different options. This can be done in two different ways. If you want to make the change globally for everyone who uses Insure, you should do the following:
    cd lib.sun4
    rm CC
    ln -s CC_old CC
    To reverse the process,
    cd lib.sun4
    rm CC
    ln -s CC_4.0.1 CC
    If you wish to make the change only for yourself, all you need to do is add the option
        insure++.compiler_acronym CC_old
        insure++.compiler_acronym CC_4.0.1
    to your .psrc file (see sections 2.2 and 2.3) as appropriate.

3.4.8 Intel x86 (SCO)

  • Undefined ctob and stoc symbols
    Some users have had a problem with these two symbols being undefined at link time. One solution is to remove the interfaces that use these functions. You can do this by executing the following commands:
        cd $INSIGHT/lib.x86/$COMPILER
        ar d tqsiic.a c12.o
        ranlib tqsiic.a
    and re-linking your program. If you then see undefined symbols of the type

    you need to add interface_ignore options to your .psrc file for each missing symbol (minus the _Insight prefix) and recompile. This will solve the problem.

    Another solution is to create dummy function calls for these missing symbols. This preserves the interface checks in the c12.o module. You can do this by either of the following two methods.

    1. Add the following lines to one of the files in your program.

        #ifdef __INSIGHT__
        void ctob() {}
        void stoc() {}
    2. Create a file dummy.c with the lines below.
        void ctob() {}
        void stoc() {}
    Compile dummy.c with cc -c dummy.c and link in dummy.o or add dummy.o to the Insure runtime library using the following command.
        ar q install_dir/lib.x86/insight.a dummy.o
  • Getting filenames and line numbers in stack traces

    To get filenames and line numbers in stack traces when compiling code without Insight (with the compiler alone), you must use the -belf option. By default, the SCO compilers generate COFF format objects and binaries.

    When Insure dynamically links applications, it links with ELF format. Therefore, all objects compiled with Insight will have file and line number information, and all objects compiled without Insight will not, unless they were compiled with the -belf option.

  • C++ filenames in stack traces and Insra
    SCO symbol tables do not encode C++ filenames with their original file extensions. All files are included in the symbol table with .c extensions. Because of this, error messages will not be able to show the actual line of source code, since Insure does not know that the file should be called foo.C instead of foo.c. This will also prevent Insra from finding the file if you double click on the live stack traces. C filenames will not have this problem, and will work normally with both error messages and Insra.

  • Old (pre-5.0) versions of SCO

    Versions 3.0 and higher of Insure++ do not work with versions of SCO older than version 5.0. One of the necessary options that is used is the -belf flag. This causes the compiler to create objects and executables of ELF object-format, which is the new format SCO 5.0 supports to allow dynamic linking. Older versions of SCO do not support this object file format.

    Therefore, if you are using an older version of SCO and would like to use Insure++, we highly recommend upgrading your SCO system to version 5.0. It is a very good upgrade.

  • Insure++ man pages
    SCO users will need to make the following links in the Insure++ man directory in order for SCO's man to find the pages.
        ln -s man1 man.1
        ln -s man2 man.2
    In addition, if you wish to preserve the processed (post nroff) form of the pages, you can also create the directories

    They must have world-writable permissions.

    A final requirement is that nroff must be installed on your system in order for the man pages to be readable.

3.4.9 Intel x86 (Linux)

Section 4 Inuse

  • 4.1 GUI does not start
    If Inuse fails to display the results of your application's memory activities, several things should be checked:
    • Is the Inuse user interface still running? You can use the "ps" command on UNIX systems to see the running processes. If there is no inuse process, you should restart it by typing inuse.

    • Do you have the "inuse on" .psrc option set? You can type "psrcdump -a -v" to see whether you have this option set.

    • Do you have the "malloc_replace off" option set in your .psrc file? Inuse requires the Insure++ memory routines, so you must link your program with " malloc_replace on" (the default) in order to use Inuse.

    If you are using the X Window System, there are two other common causes for this problem:

    • A missing or incorrect DISPLAY environment variable.

    • Trying to access a display device for which you do not have permission.

    The first problem is corrected by defining the shell environment variable DISPLAY in the window from which you start the Inuse application. Contact your system administrator or other person knowledgeable about the X Window System for help.

    The second problem can be corrected by executing the command

        xhost +
    in a window logged onto the machine whose display you are trying to use. If you find that you have to execute this command to make Inuse work, you should again contact your system administrator and ask them how they would like to set up their X Window System security.

  • 4.2 "Inuse Error: cannot bind port"
    When you start the Inuse command, you may see the error message
        Inuse Error:  cannot bind port
    or something similar. This typically means one of the following:
    • There is another copy of the Inuse user interface already running on your system, or

    • Inuse is attempting to use a port that is already being used by another application on your system, or

    • The socket connection to a previous Inuse process is still being dismantled by the UNIX operating system - a process which can sometimes take quite a while.

    If the last of these problems is causing the error, you can usually re-execute the inuse command after a short delay. Thirty seconds is typically long enough for the UNIX kernel to tear down the conflicting connection.

  • 4.3 Building your program to use with Inuse
    To use Inuse to monitor your program's memory usage, all you need to do is link your program with "insure -Zuse", e.g.

        cc -g -c foo.c
        insure -Zuse -g -o foo foo.o

    With your program built in this fashion, you will see only the memory usage of your program.

    Of course, you may use Inuse after compiling and linking with Insure, but you will also see Insure's memory usage as it does error detection.

    One thing you cannot do is compile with Insure and link with "insure -Zuse". This will cause undefined symbols at link time, since only the libraries necessary for Inuse will be added to the link line. Insure interfaces inserted during compilation with Insure will be undefined.

Section 5 TCA (Coverage Analysis)

  • 5.1 General information
    TCA is on by default, and will automatically generate the file when you compile with Insure and tca.log when you execute your program. If you would like to turn coverage analysis data gathering off, you can use two .psrc options to do so.
        insure++.coverage_map_data off
        insure++.coverage_log_data off
    will turn off coverage analysis data collection completely.

    Also by default, a banner reminding you where coverage analysis data is being written is printed at runtime. You can turn off this banner by adding the line:

        insure++.coverage_banner off
    to your .psrc file.

  • 5.2 The logfile tca.log is corrupt

    If this error occurs while running TCA, the file which contains your coverage analysis information has been corrupted. You should delete the file and rerun your application to create new data.

Tools to debug c++ and java
(888) 305-0041 Copyright © 1996-2001 ParaSoft