Insure++
Frequently Asked Questions
Revision 5.1, last updated: May 5, 2000
Please see also the new searchable, on-line support database.
- 3.1 Compiling
- 3.2 Linking
- 3.3 Running
- 3.4 Platform specifics
- 3.4.1 DEC Alpha (Digital UNIX)
- 3.4.2 DEC Alpha (OpenVMS)
- 3.4.3 HP9000 (HP-UX)
- 3.4.4 IBM RS/6000 (AIX)
- 3.4.7 Sun Sparc (SunOS 4.x, Solaris 1.x)
- 3.4.8 Intel x86 (SCO) -
Insure 3.1 only
- 3.4.9 Intel x86 (Linux)
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
support@parasoft.com
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
insure
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.
- 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"
- 2.2.3 "You have an incorrect password"
- Look for an old/incorrect 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.
$PARASOFT/lib.$ARCH/$COMPILER/.psrc
Options in this file affect everything done with the compiler
$COMPILER for all users.
$PARASOFT/.psrc
Options in this file affect everyone who uses Insure all of
the time.
$HOME/.psrc
Options in this file affect everything a particular user does with
Insure.
build_dir/.psrc
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.
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.
malloc
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.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 stretchy.data
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:
main()
{
char *ptr = malloc(10);
free(ptr);
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 foo.cc
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 libfoo.so foo.o
insure -g -o foo main.C libfoo.so
- HP HP-UX
insure -g +z -c foo.C
ins_ld -b -o libfoo.sl foo.o
insure -g -o foo main.C -L. -lfoo
- SGI IRIX 5.X
insure -g -c foo.C
ins_ld -shared -o libfoo.so foo.o
insure -g -o foo main.C libfoo.so
- Sun Solaris 5.X
insure -G -KPIC -g -c foo.C
CC -G -Bdynamic -o libfoo.so foo.o
insure -g -o foo main.c libfoo.so
- Sun SunOS 4.1.X
insure -g -c foo.C
ld -Bdynamic -o foo.so foo.o
insure -g -o main.C foo.so
- 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:
**INSURE_ERROR**
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.
-
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.
- 3.3.3.1 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
or
- 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
...
- 3.3.3.2 "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)
va_dcl
{
int j,k,i;
va_list ap;
va_start(ap);
j=va_arg(ap,int);
i=va_arg(ap,int);
va_end(ap);
k=i+j;
return(k);
}
- 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:
- 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)
3.4.3 HP9000 (HP-UX)
- 3.4.3.1 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.
CC=cc
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.
- 3.4.3.2 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''
or
``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)
- 3.4.4.1
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.
- 3.4.4.2 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)
- 3.4.7.1 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
or
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)
- 3.4.8.1 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
_Insight_*
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() {}
#endif
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
- 3.4.8.2 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.
- 3.4.8.3 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.
- 3.4.8.4 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.
- 3.4.8.5 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
cat.1
cat.2
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)
- 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.
- 5.1 General information
TCA is on by default,
and will automatically generate the file tca.map
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.
|
