@(#)r3wFAQs.htm 1.2 - 05/29/05
RECON3 Home
Frequently Asked Questions - Known Issues
1.0 General Questions
1.1 Are RECON3 and TraceGraph good at
locating bugs?
Sometimes yes, sometimes no. If the bug occurs when the
program
follows an unusual path, then RECON3 will probably find it. If the bug
depends
instead on particular data values then RECON3 may not help.
If you have a bug that occurs on some tests and not on others,
then get trace files from each test. Pass to TraceGraph first the
files that don't show the bug and then the files that do. The
red boxes will show you any code that is executed only in the
bug test cases.
If you have a program that is simply hanging, sometimes the
simplest trick is to generate a trace and just look at the
last few records for hints on what was going on just before
the failure!
2.0 Instrumenting and Compiling your Target
Program
2.1 Compile Error: "MFC apps must not
#include <windows.h>"
This message is sometimes produced when compiling the RECON3 file
r3ulbsys.h under Microsoft Visual C++. RECON3 uses Microsoft
interprocess communication API's that were in <windows.h> in
earlier versions of Windows, but that now have been moved. Changing
r3ulbsys.h to include <afxwin.h> instead of <windows.h>
seems to be a work-around. We would welcome a hint from any Windows
Guru's out there on how to write r3ulbsys.h so that it will
be portable across all Win32 platforms.
2.2 Compile error with instrumented header file:
"R3I_path_xxx redefinition"
This error can occur when you are instrumenting files, such as C++
header files, which are then included in several different ways, for
example:
|
header1.h
- uninstrumented
#ifndef HEAD1
#define HEAD1
// class C1 defined here
#endif
|
header2.h
- uses header1.h - uninstrumented
#ifndef HEAD2
#define HEAD2
#include "header1.h"
// class C2 defined here - uses C1
#endif
|
|
header1.h
- instrumented
#include "r3.h"
#include "r3ctminf.h"
static char *R3I_path_848="F:\\header1.h";
#ifndef HEAD1
#define HEAD1
// class C1 defined here
#endif
|
header2.h
- uses header1.h - instrumented
#include "r3.h"
#include "r3ctminf.h"
static char *R3I_path_221="F:\\header2.h";
#ifndef HEAD2
#define HEAD2
#include "header1.h"
// class C2 defined here - uses C1
#endif
|
As you can see, the instrumentor inserts the static variable
R3I_path_xxx near the top of each file.
Unfortunately, if some other file now includes BOTH header1.h and
header2.h, the compiler will see the definition of R3I_path_848 twice,
once when it parses header1.h and again when header1.h is included in
header2.h. The solution may vary depending on your system, but one good
work-around is to move the definition of R3I_path_848 to after the #ifndef
HEAD1 so that it will be seen only once, just as the class
definition is seen only once.
2.3 Instrumentor inserts calls to R3TmiEntry()
and R3TmiReturn() at the wrong places
When you choose "subroutine entry" and "subroutine return"
instrumentation, the C instrumentor scans through your target program
trying to identify the first and last line of each function.
Unfortunately it can be easily confused, for example by the C/C++
preprocessor. If your instrumented code contains many errors of this
nature we suggest you choose "decision" instrumentation only. In this
case the scan looks for "if", "while", "for" and similar keywords and
is much more robust. We have generally found that, in practice,
decision instrumentation is as good or better than entry and return
instrumentation for locating features.
3.0 Running and Monitoring your Target Program to
Produce Traces
3.1 The first trace records go to default.r3t
When the trace manager client starts up, its first trace file is always
called default.r3t and it generally goes into its current working
directory, wherever that may be. If you use the Trace Manager GUI or
the r3ctmc command to specify a different trace file name or a
different trace file directory, your change does not take effect until
after the trace manager client starts, so the first few trace records
may be in default.r3t.
4.0 Anayzing Traces with TraceGraph
4.1 What test cases work best
to locate a feature in code?
Simple ones! In general, one or two cases "with" the
feature you are looking for and one or two "without" seems to
work best. Keep the "with" test cases as simple as you can and
make the "without" cases similar to them, but omitting the desired
feature.
For example, suppose you are trying to locate the code that
scrolls
a screen window. Let us assume that you are using the RECON3 Basic
Architecture, so each complete test case produces a trace file,
probably called default.r3t.
Do one case that opens the simplest window you can think
of and then closes it. Rename the trace file, eg.
to test1.r3t. Then do another case that opens the
same window, scrolls it, and then closes it. Rename the trace file, eg.
to test2.r3t. Start up TraceGraph, open a "Continuing
Directory" trace source on some directory, and then drop the two
trace files into that directory in order. The red boxes that show
up in the second row of the display should point you to the scrolling
code.
4.2 Exception
java.lang.ArrayIndexOutOfBoundsException
TraceGraph occasionally throws this exception but continues executing.
This seems to occur because two processes are updating the GUI
simultaneously. It does not affect your results.
![[UWF Argonaut Logo]](r3wArgo.jpg)
Email suggestions or questions to:
Norman Wilde