As of November 2007
Copyright © 2004—2007 SofCheck, Inc. All rights reserved.
The use and distribution of this material is subject to licensing terms.
This document describes how to run the SofCheck Inspector, the advanced static error detection tool, and interpret its output.
About SofCheck Inspector |
top |
SofCheck Inspector is a static error detection tool that automatically identifies possible programming errors and verifies logical correctness, without relying on labor-intensive run time testing. It integrates into existing development tools and processes.
SofCheck Inspector performs line-by-line testing in a fully automated way, and guarantees full path coverage. SofCheck Inspector finds defects early in the development process—in conjunction with compilation—when they are least costly to repair. In addition, it should be run on existing code to find latent defects before they become a problem in the field.
SofCheck Inspector is designed to support large systems and to detect a wide range of programming errors such as misuse of pointers, indexing out of arrays, buffer overflows (a prevalent source of security storage leaks,) numeric overflows, numeric wraparounds, and improper use of Application Programming Interfaces (APIs). It pinpoints the root cause of each error down to the source line of code.
Even in the absence of explicit errors, SofCheck Inspector provides a thorough characterization of every component of the system in terms of its inputs, outputs, heap object creations, the preconditions on the inputs necessary to preclude run-time failures, the presumptions about return values of external methods, and the postconditions that characterize the range of outputs.
An inspection may be launched from the command line or interactively, using the SofCheck Inspector Console or one of our plugins for popular IDEs.
How to Run SofCheck Inspector |
top |
System Requirements |
SofCheck Inspector analyzes Java that has been compiled into bytecodes. The .class files which contain the JVM bytecodes define the scope of the inspection. for the best results, inspect bytecodes compiled with full debugging information . Full debugging information can be generated by passing the -g parameter to the Java compiler. Corresponding source in .java files is not required, but should be provided if possible so pre- and postconditions and inspection messages may be interspersed within source listings for ease of understanding.
SofCheck Inspector Console |
Launching Console |
Launch the Console by selecting the Start > Programs > SofCheck Inspector > Inspector Console menu item. Alternately, you may execute the RUNCONSOLE.BAT file from the command line. The Inspector Console main window will appear.
The Project drop-down menu lets you create, open, edit and save Inspector project files. The Run drop-down menu lets you launch SofCheck Inspector, monitor its execution, and view its output. The Help drop-down menu lets you view this document and other helpful information.
The Console text area displays diagnostic output from the SofCheck Inspector. The other output of the inspection is written to the file system in the form of HTML files, text files, and the Inspector Database.
Console Project Menu |
top |
New Projects |
Select Project > new… (or press Ctrl+N) to create a new
Inspector project. You will see the following Project Description dialog: Enter a Project Name for your Inspector project. The Project Name
should conform to an acceptable directory name to be saved to the native file
system. Click on the Create button to the right of
the edit box, and the Project Name will be used to complete the Project
Information fields; at this time, the Project Directory and error.txt
log file are also created. For example, type
"MyInspection1" in the Project Name edit box and click the
Create button.
The Project Information fields will be completed as in the following dialog: You may accept the default names for the project files and directories
listed in Project Information or select the Customize Project check box
to change them. for each entry you may type new values into the edit boxes or
click on the Browse buttons to
select existing files. For example, you may wish to have multiple projects use
the same database, or you may have an alternate Message Pattern File which you
wish to use. for a Java project, click the Source
Files Select… button
to select one or more source files that correspond to the class files being
inspected. You will be able to browse a source tree and select source
directories, source files, and archives. For Java, it is the class files that
determine the scope of the inspection. As such, selecting source files is
optional, but is recommended so that the Inspector can display inspection
messages in-line with the source for better context. The following is an example of a Java Project Source Files selection dialog: Inspector is able to match source files to their associated class files
properly. If you select source files that do not correspond to selected class
files, corresponding entries will be listed in the Source Directories
that lack classfiles pane. Inspector cannot analyze source files without corresponding class files.
Similarly, if you select class files without selecting their associated source
files, corresponding entries will be listed in the Class Directories that
lack sources pane. In this example, the appropriate class files
haven’t been selected yet, which is why there are mismatched sources/classes. Click on the Show Project Issues button
to display a text list of file-selection issues (such as duplicate .java files). Click the Done button to return to the Project Description
dialog. From the Project Description dialog, click the Class Files Select…
button to select one or more class files to be inspected. You will be able to browse a source tree and
select class files and archives (including .zip, .jar, .ear and .war files).
You must select at least one class file for an inspection to succeed. The following is an example of a Java Project class Files selection
dialog. In this example, corresponding source files have already been selected. In the source tree, if a class file lacks debug information, that file and
its parent directory are highlighted in yellow. If an archive
contains a nested archive, that archive and its parent directory are
highlighted in red. Inspector does not analyze nested archives;
if any are found, they should be extracted to the file system before running Inspector. As mentioned above, if you select source files that do not correspond to
selected class files, corresponding entries will be listed in the Source
Directories that lack class files pane. Similarly, if you select class files
without selecting their associated source files, corresponding entries will be listed
in the Class Directories that lack sources pane. Click on the Show Project Issues button to display a text list of
file-selection issues (such as duplicate .java files). Click the Done button to return to the Project Description dialog. The Project Description dialog will indicate that source and class files
have been selected, by changing the status message from Not
Selected& to Selected, as shown below. Click on the Options button
to modify the project’s run time parameters. The following dialog will appear: Find out more about Inspector run time parameters in the “
Command Line Options”
section. Brief explanations are given below. In the Project Options dialog, click on the Cancel
button to return to the Project Description dialog without preserving any
changes. Click on the OK button
to preserve changes and return to the Project Description dialog In the Project Description dialog, click the Save
button to preserve all changes made in the dialog. for a Java Project, if the Validate
Mode check box is checked, the Console will examine and validate the
class file and source file selections when the project is saved. It will check that class files are compiled
with debug information, that class files have corresponding source files, that
source files have corresponding class files, and that nested archives (e.g.
jars within jars) are not present. Check the validity of the file selections
at least once after they are changed, before inspection. You may be warned that the validation process may take a long time with the
following dialog box. This it typically not a problem with small projects. If you see the above dialog, click Yes to proceed
with validation and save the selected classes and source files; you will return
to the Console main window. Click No to save the
class and source selections but return to the Console main window without
validating them. Click Cancel to return to the
Project Description dialog and continue to make changes. If you click
Yes, the
Console main window will display the summary of the validation, and the details are saved
in error.txt. If you have not already specified a name for the Console Project File
(with a .prj
suffix by default), the Console will prompt you to enter one (See Project
> Save As...), below. In the above example, some problems were found with the class and source file
selections and the reults were written to error.txt. Select Project > Open... (or press Ctrl+O)
to open a project file that has been previously saved. You will be prompted to browse for a file on the
file system. By default, Inspector project files end in the suffix
.prj. When a
project file is opened, the Project Description dialog will appear. Select Project > Edit... (or press Ctrl+E) to edit the current
project file. The Project Description dialog will appear. Select Project > Save As… (or press
Ctrl+A) to save the project you
are currently editing. You will be prompted to type a filename for saving. When you are satisfied with the location and name of the project file, click
the Save button to save it. Select Project > Quit (or press Alt+F4)
to exit the Inspector Console. If you quit the Console while an inspection is
running, the inspection will be terminated. Select Run > Inspect Project … to start the
inspection as defined in the currently open project. First, the Estimated Run
Time dialog will show an estimated count of lines and classes and give a rough
estimate of the expected run time for the inspection. The actual run time may
vary by an order of magnitude from the estimate due to variations in code
complexity and server hardware, but changes in the estimate from inspection to
inspection on the same hardware should give a more reliable indication of
relative time. Note that if the class files have not been compiled with debug
information, the Console will not be able to estimate a run time. When you run
an inspection for the first time, the Output Directory and the Database
Directory are created. Select Run > Regenerate Reports … to regenerate
text and html reports for an existing Inspector analysis. This is useful if you have modified the
Message Pattern File, or if you specify a new cutoff inspection id
against which to compare the current inspection results. It does NOT perform a new analysis of the
code. In the Estimated Run Time dialog, click the Run Now
button to begin the inspection or the Cancel button
to return to the Console run menu. When you click on the Run Now button to
start the inspection, progress messages will be displayed in the Console main window,
as shown below. Select Run > Clear Console (or press
Ctrl+C) to clear any text in
the Console text area. Select Run > Browse Output (or press
Ctrl+B) to launch a dialog that will open the
“./html/index.html” file in this project's output directory, which
enables you to easily browse all output from the run of this project. this
option will only work if output has already been generated to the output
directory specified in the project information settings. If an inspection is
still running, you will see a warning dialog box. Click OK to dismiss the dialog; any running inspection will continue. if an
inspection is complete, you will be allowed to select the output index.html
file as shown below. In the Browse Output Folder dialog, click on the OK
button to browse the specified index.html file in your system's default
browser. Optionally, click the Browse button to
select another HTML file. Click the Cancel button to
dismiss the dialog without launching the browser. Select Run > Show Project Issues... (or press
Ctrl+I) to open the error.txt file in your default text editor. The
error.txt file captures the results of validating a
project file after class and source selection, and in particular points out any
duplicate or missing files.
Select Help and then one of the following Help Menu items for more
information. 
Selecting Files to Inspect
Saving a Project.
Existing Projects
Console Run Menu
Console Help Menu
How to View SofCheck Inspector Output |
top |
Browser Requirements |
top |
The output of SofCheck Inspector may be browsed via recent versions of Internet Explorer, Netscape Navigator, Mozilla, or Firefox. Verify that your browser's security level is set to enable JavaScript, to allow popup windows, and to allow the JavaScript to raise and lower windows (see below).
On more recent versions of Internet Explorer, you will need to allow windows to use active content (i.e. JavaScript) by going to Tools->Internet Options->...Advanced, scrolling down to the Security check boxes, and checking the box that says "Allow active content to run in files on My Computer".
On more recent versions of Firefox, you will need to allow JavaScript to raise and lower windows. This is done by going to Tools-->Options-->Content-->Advanced button next to the Enable JavaScript (which should be checked also), and then making sure that the "Raise or lower windows" box is checked.
Location and Format of Output |
top |
SofCheck Inspector's output is generated in the Output_Directory. Output is generated in two formats, both of which preserve the Java package/source file hierarchy. The recommended format is HTML, suitable for display by a browser. It is produced under the html subdirectory of the Output_Directory. A more traditional interleaved source and inspection message listing is produced under the list subdirectory of the Output_Directory. The contents of the list subdirectory may be displayed with any ASCII text viewer.
To look at the output, point your browser at html/index.html, in the Output_Directory.
Back and Forward Buttons |
top |
The back button (<<) and forward button(>>) are located in SofCheck Inspector's titlebar. Use these buttons to navigate through the command history associated with the large right panel of the main window. These buttons will work more predictably than the browser's built-in back and forward buttons, because of the multi-frame user interface provided by SofCheck Inspector. The browser's built-in back and forward buttons work fine with the other windows (Message History, Race Conditions, Class List, and Help windows).
Main Window |
top |
The Main Window is composed of up to four panels, with a titlebar across the top. The Partition panel in the upper-left panel contains a list of the partitions into which the Inspector has broken up the system for more efficient analysis. Click on All Partitions to display all directories and files, or click on a named partition to filter directories and files to those inspected within that partition. The Partition panel will not be present if the inspection was performed as a whole and no partitions are created. The -global command line flag instructs Inspector to avoid making partitions; Inspector may not create partitions if the analysis is small.
The Directories panel on the left, below the Partitions panel (if your project has partitions), lists all directories in which the Inspector found source code. Click on All Files to list all files associated with all directories in the Files panel, below. If you are viewing only a single partition, click on “Partition n Files” to list only those files within partition n in the files panel. Click on a single directory to list only its files in the Files panel.The Files panel on the left, below the Directories panel, lists source files analyzed by the Inspector. A “-” to the left of the file indicates that the file has been dropped since the base inspection; a “+” indicates that the file has been added since the base inspection. Initially, the Files panel shows all of the source files in the system, across directories and partitions. Filter the list by selecting a single partition in the Partitions panel. You may also filter the list by selecting Partition n Files or a single directory in the Directories panel. Click on a file name to view the File Summary, described below.
In the Main panel on the right, you may click on one of three tabbed views: Inspection Overview, File Summary, and File Source.
The Inspection Overview view shows the inspection's File Hot Spots, a sorted list of files, those with the most important inspection messages listed first. Importance is ranked according to an algorithm that considers the number, a calculated degree of priority, and newness of inspection messages. In the header, the Current Inspection shows the date and number of the inspection run that generated this output, whereas the Base shows the date and number of the base inspection. The base inspection is a prior inspection against which the current inspection is compared, to determine changes since a prior run.
For each of the files, a set of columns show the numbers of high, medium, and low probability inspection messages. The higher the probability, the greater the likelihood the indicated line of code would fail when executed. Each probability category has three columns: base, deltas, and now. The base shows the total number of inspection messages that were found in the base inspection in each file. The now column shows the total number of inspection messages that are found in each file for the current inspection. The deltas column shows how many unique inspection messages were dropped and/or added between the base and current inspection in the form dropped/added, e.g. “-2/+5” means that two messages were dropped and five new ones were added. Click on an individual file name to display its File Summary.
If any of the files have been added (“+”) or dropped (“-”) since the base inspection, the File Hot Spots table will have a “-/+” column to mark the file in this way. Dropped files (i.e., files that were present in the base inspection, but are not in the current inspection) appear at the end of the table, after the files for the current inspection. Clicking on the name of a dropped file will bring you to its File Summary view, but because the file is not part of the current inspection, you will not be able to access its File Source view.
The File Summary view shows a file's Method Hot Spots, a sorted list of methods, those with the most important inspection messages listed first. As for the Inspection Overview, importance is ranked according to an algorithm that considers the number, a calculated degree of priority, and newness of inspection messages. The following section will list a method summary table for each method that has inspection messages. If there are no inspection messages for the file, there will be no Hot Spots or Method Summary tables. The last section lists all methods, even those with no inspection messages, with links to jump to the source for each method. If a method name has a hyperlink, clicking on it will bring you to the Method Summary table in the File Summary view.
The File Source view shows an annotated source file listing for the current file. If no source was available for a .class file that was inspected, only the annotations will be displayed. The source is interspersed with preconditions and postconditions, lines with added inspection message indicators (“+” to the left of the line number), and color-coded hyperlinks to the inspection messages. Click on the Precondition/Postcondition indicator (“P/P”) near the top of a method's definition to show a list of all preconditions and postconditions in the bottom view pane.
Click on a color-coded, hyperlinked line to show the associated inspection message(s) in the bottom view pane. The colors are assigned according to the highest probability message associated with any one line, red for high, yellow for medium, green for low. Each inspection message will show a blank or “+” indicator (“+” indicating this message is new in the current inspection), a message category, a high/medium/low probability indicator, and a detailed text description. Click on Prev Msg or Next Msg to view the previous or subsequent inspection message for the file, respectively. Click on the Edit Icon, the image of a pencil-and-paper to the left of the probability indicator, to open the Per File Message Status Window.
Click on the Inspection Overview, File Summary, or File Source tabs to alternate between views. Remember to use the << and >> buttons in the Inspector titlebar to navigate back and forward, respectively, between viewed pages. (Avoid using the browser's default back and forward buttons, since they may lose track of your view state information.)
Race Conditions Window |
top |
Click on the Race Conditions button in the titlebar to view the Race Conditions report. The button is suppressed if the inspection was performed with the -no-race-conditions command line option. See the section Identify Possible Race Conditions for a description of how to interpret the results of the race condition analysis.
Message History Window |
top |
Click on the History button in the titlebar to view the Message History report. This button is visible only if a Database_Dir has been specified in the library file (see above) for the current inspection and the user has not specified the -no-error-history command line option. This report contains a table of the number of messages identified in every inspection, in total and grouped by each directory of sources, since the database was created. Each row corresponds to an inspection. Rows of baseline inspections appear darker.
At the bottom of the Message History report is a histogram of the total number of errors over time, with one column per inspection.
Note: for the Message History Report, each message in the database is evaluated relative to the current inspection, the current base inspection, and the current MessagePatterns.xml file. As a result, the message counts for prior inspections may vary from those counts that were reported at the time of the actual inspection.
Class List Window |
top |
Click on the Class List button in the titlebar to view a list of all classes inspected in the current run. Click on a class in the left pane, and the right pane will display detailed information including the source file, superclass, and a list of virtual methods, constructors, static methods, instance fields, static fields, and references to other classes. The methods and fields of each class inherited from its superclass are displayed using an italic font. Methods and fields directly defined on a class are displayed using normal font. In the right pane, click on the superclass or a reference to another class to jump to it in the Class List. Methods with inspection messages will have hyperlinks. Click on a method hyperlink or the source file hyperlink to jump to the File Source view.
Message Status |
top |
Click the Messages button in the titlebar to open the Message Status Overview window. This window contains a system-wide summary of the messages organized by Message Category, and again by source file. The Message Status Overview allows you to sort/filter system-wide summaries of inspection messages and to access per-file summaries.
For each row in the Message Category Table, the message count for each category is further broken down by High/Medium/Low probability.
Uncheck the Select box for a message category to suppress that category from appearing in the Source File Table.
Each row in the Source File Table is uniquely defined by source file and message category. The message counts are subtotaled for each category of messages in a source file. As with the Message Category Table, each file-category row has High/Medium/Low probability columns. File-category rows with zero inspection messages are not shown.
Click on a column header to sort the display by that criterion. Sorting large tables can take a long time. While the sort is being performed, the column header will be highlighted, and a Stop Sort button will appear at the top of the window. You may continue working in other areas of the browser while a sort is running, although performance may be slowed. The Stop Sort button will disappear when the sort finishes. Click on the Stop Sort button to stop a sort before it finishes.
Click on a Source File Name in the Message Status Overview window to navigate to the detailed message list for that file.
Alternately, open the detailed message list for a file by clicking on the edit icon which also appears
Note : This message-edit functionality requires that Google Gears be installed on your system. Google Gears is an open source browser extension that enables web applications to provide offline functionality using JavaScript APIs. Google Gears is supported on Firefox 1.5+ and Internet Explorer 6.0+ on Windows Vista/XP. If Google Gears has not been installed and you try to edit a message, a button will be provided for you to Get Google Gears. At that website, simply click the "Install Google Gears" button to download it and run the Google Gears installer. After the installation, you will need to exit your current browser session, and then start a new one, for the message-edit functionality to be available.
At the upper-left of the window, the Filter Options grid contains checkboxes to control which messages are displayed. for History options, check added to select messages that were not in the base inspection but appear in the current inspection, dropped to display messages that appear in the base but not in the current inspection, and unchanged to display messages that appear both in the base and current inspections. For probability, check High, Medium, and Low to display messages with corresponding current probabilities.
By default, added, unchanged, and dropped messages are displayed, for High and Medium probabilities; Low probability messages are hidden. You may check a box to show the corresponding messages, or uncheck the box to hide them. The filtering options selected affect all files, not just the one whose messages are currently being displayed.
Click on any of the hyperlinked column headers to sort by that column, which can be Status, +/-, Msg Id, Method, Line, or Message Category. Sorting columns in this window uses your browser's build-in sorting capability, and may be unresponsive during a sort. Most sorts should complete in a reasonable amount of time.
The Status column displays the current probability for a message. The Review button indicates that the message has yet to be reviewed, while the Edit button indicates that the message has already been reviewed/modified. Both buttons bring up a popup window through which the user can change the probablity of the message and/or add comments to it. The history of all changes made to the message is also displayed. for a message that has yet to be reviewed, click on the Mark As Reviewed button to confirm the probability assigned by the Inspector; this will also automatically add a comment to the message, with the timestamp of the review.
Changes which you make during your current browser session will be reflected in the Message Status window and corresponding File Source view; however, they will not be fully incoporated into the output (i.e., in any of the Overview tables, or in the message-status Change History) until the Inspector is re-run. From the Inspector Console, choose the Run->Regenerate Reports menu item to fully incorporate the latest message edits *without* rerunning the analysis engine. This will also pick up any changes made by others on your system who have been examining the same output. (Note : Even if you do not re-run the Inspector, changes that you make in one browser session will be available in subsequent browser sessions. However, the color-coding of source lines in the File Source view (based upon message probability) may not be accurate until the corresponding Message Status window is loaded.)
The Msg Id column contains Inspector-generated message identifiers used to uniquely identify each inspection message. Click on a Msg Id to jump to the File Source view for that message.
Annotations Report |
top |
Click the Annotations button in the titlebar to open the Annotations Report window. This window contains a system-wide summary of annotations per file, with deltas.
Click on a file to get a detailed view of annotations per method, including some history information, filterable by annotation kind, and whether the annotation is new, unchanged or dropped.
Help Window |
top |
Click on the Help button in the titlebar to view this SofCheck Inspector User Guide.
Non-Web Output (list subdirectory) |
top |
In addition to the files in the html subdirectory, there are listing files in the list subdirectory of the Output_Directory, each with the suffix .txt. These files contain source listings interleaved with SofCheck Inspector messages. Some of the information in these listings is at a lower-level than that displayed in the browser. We suggest initially viewing the output through the browser interface. The listings may be used for more detailed analysis, if desired.
The overview.txt file in the list subdirectory provides aggregated message information in a series of tables using comma-separated list format, each intended to be suitable for import into a spreadsheet.
The Inspector creates a test_vectors.txt file directly in the output directory (as opposed to in the list or html subdirectory). This file contains a report which, for methods that have any significant control flow (if/while/for statements), identifies the distinct ranges of values for inputs (or combinations of inputs) that will ensure that each block of code is executed. for example, if the report includes:
Graph.Util:Get_Value
X: {0..2}, {3..2_147_483_650}
X - Y: {-inf..0}, {1..+inf}
This means that if you want to have run-time tests that exercise all blocks
of code in the Get_Value routine in the Graph.Util package, you will need
to write tests where there is at least one test that has X in
the range 0 to 2, and a separate test where X is greater than 2.
Similarly, you will need to write at least one test with
X <= Y,=Y, AND=and ONE=one WITH=with X=X> Y. And to be safe, all combinations
of these two alternatives should be tried (leading to a total of at least
four tests of Get_Value).
The Inspector determines these test vectors as a side-effect of its control and data flow analysis of each method. The test vector report can help a project achieve higher coverage in run-time functionality tests to complement the full coverage static error detection tests provided by the Inspector.
Messages and Annotations |
top |
SofCheck Inspector output is comprised of messages and annotations. The types of messages and annotations produced are described below. For an overview of SofCheck Inspector's output, refer to the How to View SofCheck Inspector Output section.
Description of Messages |
top |
SofCheck Inspector uses static analysis to track possible run-time values of all variables, parameters, and fields at each point in the source code. using this information, it identifies conditions under which a Java run-time check might fail (null pointer, array out of bounds, etc.), an exception might be thrown, a user-written assertion might fail, or a numeric calculation might overflow or wraparound.
The messages that the Inspector emits, when it detects one of the above conditions, are referred to as Check-Related Messages. The Inspector's titlebar displays the Total Checks Analyzed (i.e., the total number of such checks that it performs as part of its static analysis over the entire program), as well as the Total Checks Passed (i.e., the number of such checks that it determines will pass). The Percentage Passed statistic is an important metric to help you track the overall quality of your code, or determine the quality of third-party or outsourced code. Each file's File Summary page will also display the same check-statistics, on a per-file basis.
Some messages that the Inspector emits do not fall into the Check-Related category. These messages are "suspicious preconditions", as well as the race-condition messages and the code redundancy messages (see below). The Hots Spots tables, in both the Inspection Overview and File Summary pages, display the total error-counts using a breakdown of Check-Related Messages and Other Messages.
The messages produced by SofCheck Inspector indicate particular lines of source code that could cause a crash or questionable behavior at run time. The reason is given (such as “array index out of bounds”), along with a rough indication (based on heuristics) of the likelihood that this message identifies a defect that could lead to incorrect results in actual usage of the program. Occasionally a message contains too much information to fit conveniently on the screen. In that case the message will be truncated and will be replaced with an ellipsis (“...”) as indication that truncation has occurred. The complete text of the message is available for viewing in the corresponding .txt file.
These are the messages produced by SofCheck Inspector. NOTE: CWE refers to the Common Weakness Enumeration, a community-developed dictionary of common software weaknesses, hosted on the web by The MITRE Corporation. The numbers following CWE are the indices into the CWE dictionary, for weaknesses that correspond to the given Inspector message.
| Message | Description |
| array index out of bounds | Index value could be negative or greater than or equal to the array length (CWE 124, 125-127, 129, 130, 131, 132, 135, 193). |
| null dereference | Attempting to dereference a reference that could be null (CWE 252-253, 476). |
| precondition failure |
A method call that might violate the method's preconditions.
NOTE: in the message in the frame at the bottom of the window, the precondition being checked is expressed in terms of the variables of the called method, rather than the calling method. this means that it is wise to click on the link provided to view the preconditions and local parameter names of the called method, and then click the Back button ("<<"), before trying to understand in what way the caller might be violating the precondition. See Description of Annotations, below, for more information on preconditions. |
| divide by zero | Second operand of a divide or mod operation could be zero (CWE 189). |
| throw exception | An exception is being thrown on a reachable path. |
| conditional throw | An exception could be thrown depending on the outcome of a conditional test or assertion in the code. |
| overflow | A calculation may overflow the bounds of a numeric type and wrap around. The likelihood this will affect operation of the program depends on how narrow is the range of the numeric value (CWE 128, 190-192, 197). |
| use of default init | The code is relying on the default initialization of a field to zero or null. (An explicit initialization to zero or null would not produce this message.) (CWE 232, 236, 475) |
| call too complex; analysis skipped | Indicates that the Inspector skipped analyzing the method call to avoid exhausting resources needed for analyzing the remainder of the system. The Inspector will report any presumptions it makes about the results/effects of the otherwise unanalyzed call. These should be reviewed to be sure they are appropriate. |
| method not available; call not analyzed | Indicates that the Inspector cannot analyze the call because the called method is not available. There are two possible reasons for this: the .class file for the called method is not supplied in the library file, or the called method is analyzed in a different partition. The Inspector will report any presumptions it makes about the results/effects of the otherwise unanalyzed call. These should be reviewed to be sure they are appropriate. |
| method fails for all possible inputs | Indicates that a run-time problem is likely to occur on every execution of the method. |
| method does not return | The method will never return, presumably because of an infinite loop. |
| suspicious precondition | The precondition has a form that indicates there might be a problem with the algorithm. if the allowable value set of a given input expression is not contiguous, that is, there are certain values of the expression that might cause a run-time problem inside the method in between values that are safe, then this might be an indication that certain cases are not being properly handled by the code. In other situations, this might simply reflect the inherent nature of the algorithm involved. |
| unused assignment | Indicates redundant assignment. this may be an indication of unintentional loss of result or unexpected flow of control (CWE 563). |
| dead code | Indicates logical errors as the programmer assumed the unreachable code could be executed (CWE 561). |
| test always goes same way | Indicates redundant conditionals, which could flag logical errors (CWE 561). |
Race Condition Messages |
top |
SofCheck Inspector produces three sorts of race condition messages. See Identify Possible Race Conditions for details on using the SofCheck Inspector to perform race condition analysis. Note that when the Inspector indicates that no lock is held, it actually means that no lock visible to multiple threads is held. There may in fact be a local lock held. See Identify Possible Race Conditions for more information on the handling of local locks. See above for an explanation of the CWE references.
Message |
Description |
|---|---|
| unlocked reentrant update | A reentrant external entry point updates a potentially shared object without holding a lock. The message is associated with places where the object is updated in the absence of any lock, or with non-overlapping lock configuration (CWE 366-367, 373-374). |
| unlocked shared daemon update | A daemon entry point updates a potentially shared object without holding a lock, and this object is also referenced (read or updated) by some other entry point. The message is associated both with places the daemon updates the object, and places that reference the object outside the daemon (CWE 366-367, 373-374). |
| mismatched locked update | An entry point updates a potentially shared object while holding a lock, and this object is also referenced (read or updated) by a second entry point without holding the same lock. Any messages are associated with the second entry point's references (CWE 366-367, 373-374). |
If Inspector indicates a race condition at a particular line in your program, it is best to refer to the Race Conditions report by clicking on the Race Conditions button in the titlebar. The Race Conditions report is organized by the affected object, and gives an overall perspective on how the various thread entry points are involved in creating the potential race condition on the given object. See Identify Possible Race Conditions for more information on how to interpret this report. Note that the current release of Inspector does not detect deadlocks between threads(sometimes called “deadly embraces”). Rather it identifies data objects that are potentially referenced without adequate synchronization.
Categorization of Inspection MessagesCategorization of Inspection Messages |
top |
SofCheck Inspector makes conservative assumptions in order to avoid missing potential problems. Because of these assumptions, SofCheck Inspector might generate inspection messages that a programmer would decide are not true problems, or that are problems that would not occur during a normal execution of the program. for example, a given numeric overflow might occur only if the program ran continuously for decades. Inspection messages that are not true problems are called false positives.
To help deal with false positives, SofCheck Inspector categorizes inspection messages into three levels, according to the likelihood the message corresponds to a true problem. For example, a "divide by zero" error might be categorized as "high." An "overflow" that only occurs near the limits of the maximum long integer value, however, might be categorized as "medium," especially if there are intermediate exit points in the loop that would prevent the overflow. Use of a global variable that is not explicitly initialized might be categorized as "low" because Java provides well-defined default initial values for all globals. These levels are determined by matching against patterns provided in a MessagePatterns.xml file. With guidance from SofCheck, this MessagePatterns.xml file may be used to tune the categorization of messages to the needs of a particular project.
Probability |
Description |
High |
High likelihood there is a defect on this line of code. It is likely to cause a problem on every execution. |
Medium |
Moderate likelihood there is a defect on this line of code. It may cause a problem on some executions. |
Low |
There is a small chance there is a defect on the given line of code. It is worth investigating when trying to eliminate any possibility of incorrect execution. |
The following terms are used to distinguish between different inspections and messages when an historical database is being maintained for a body of code.
Qualifier |
Description |
current (now) |
A current inspection message is one that appears in the current inspection, regardless of whether it appeared in any prior inspection. if no historical database is being kept, all inspection messages are current. The current inspection is always the inspection currently being viewed though the SofCheck Inspector browser interface. |
new (added) |
A new (or added) inspection message is one that appears in the current inspection but not the base inspection. new inspection messages have a "+" indicator in the left column in the File Source view and in the +/- column in the Per-File Message Status Window. If no historical database is being kept, the new designation is not made. |
dropped |
A dropped inspection message is one that appears in the base inspection but not in the current inspection. Dropped inspection messages have a "- quot; indicator in the +/- column in the Per-File Message Status window. if no historical database is being kept, no dropped messages will be displayed. |
base (baseline) |
A base inspection message is one that appears in the base inspection, regardless of whether it appears in the current inspection. The base inspection is a prior inspection against which the current inspection is compared, in the Inspection Overview. Any Inspection Overview has exactly one base inspection, or none, if no historical database is specified. A baseline inspection is an inspection run with the -baseline run time option. this makes the inspection eligible for being used as the default base inspection for future inspections, in the absence of an explicit -cutoff parameter. There may be many baseline inspections over time, but not all inspections are baseline inspections. |
deltas |
The deltas column contains the count of messages dropped (-) and/or added (+) between the base and the current inspection. |
Where an historical database is specified, the Inspection Overview's base inspection defaults to be the second most recent baseline inspection, one run with the -baseline command-line flag. Use the -cutoff flag to override the default base inspection by assigning the inspection ID of an arbitrary inspection to be the base.
Inspector uses the historical database, the message type, and the line number on which the message is associated to determine whether a base message matches a current message or the current message is new. Each new inspection message is assigned a unique identifier, and that identifier is maintained across subsequent runs. If the source file has been modfied significantly between base and current inspections, Inspector may not be able to determine that a current message matches a base message. In this case it will designate the current message as new. Similarly, if Inspector cannot read the historical database for any reason, it will determine that all current messages are new.
Description of Annotations |
top |
SofCheck Inspector generates the following kinds of annotations on each Java method. See Use Annotations for Code Review below for a discussion of how annotations can be used to aid in source code review.
SofCheck Inspector Usage Scenarios |
top |
SofCheck Inspector ideally should be used early in the development cycle, as soon as there is code that compiles. Thereafter it may be run every day, or as often as there is a build of some part of the system. In general, SofCheck Inspector is best suited to be used during periodic (daily) system builds, with its output made available to all relevant parties. It requires compiled JVM byte codes, but can operate on less than an entire system. Since static analysis does not require running code, SofCheck Inspector may perform its analysis at the point of unit, integration, or system build—even before any run time testing has been performed. By using SofCheck Inspector to find defects before they enter run time testing, it will minimize the number of crashes encountered during testing, allowing functional tests to run to completion and thereby provide usable output for test engineers.
Various types of users may take advantage of SofCheck Inspector. Here are some examples:
The following scenarios illustrate how SofCheck Inspector can be used to:
Find Defects in Code |
top |
SofCheck Inspector helps the review of inspection messages by categorizing them into High, Medium, and Low probability, reflecting the descending likelihood that a given message corresponds to a defect that will cause a problem during actual use. In addition, High probability messages are less likely to be false positives, while it is more likely that a Low probability message might correspond to a false positive. When starting to inspect a codebase, we recommend focusing on High probability messages, while initially ignoring Medium and Low probability messages. When High probability messages have been understood or remedied, consider the Medium probability messages. Only those developing mission critical systems might eventually want to systematically review all the Low probability messages. As discussed below, by taking advantage of the Inspector's historical database capability, you can easily identify just new messages that correspond to recently modified code. In addition, since the Message_Patterns file that determines how inspection messages are categorized can be tuned, most users can focus their attention on High and Medium probability messages.
By specifying a Database_Dir in the Library File, you can request that SofCheck Inspector keep an historical database of inspection messages, to allow it to differentiate messages that appear as added (not present in an historical base inspection, but present in the current inspection), dropped (present in a base inspection, but not in the current inspection), and unchanged (present in both a base inspection and the current inspection). The base inspection is either the most recent inspection (prior to the current inspection) run with the -baseline parameter or a prior inspection identified by the -cutoff parameter in the current run.
For a library with an historical database, it is reasonable to investigate just the new Medium and Low probability messages rather than reviewing all such messages. There are generally far fewer new messages, and new messages should be related to recent code changes. Therefore, even Low probability messages might be worth reviewing when marked new.
For inspection messages that are not deemed to be critical errors, revising code to alleviate the identified issue might still be useful, to make the code easier to understand for human readers, and to help make the code less vulnerable to future problems as it undergoes maintenance.
Use Annotations for Code Reviews |
top |
Whether it is a formal team process or an ad-hoc, one-person activity, manually reviewing source code is a good way to identify problems early in the development cycle. Unfortunately, it can also be quite time consuming, especially when the reviewer is not the author of the code. SofCheck Inspector reduces the effort required for understanding source code by characterizing the input requirements and the net effect of each component of the code base.
Specifically, SofCheck Inspector determines preconditions and postconditions for every Java method it analyzes. It also makes presumptions about external methods it calls whose byte codes are not available for inspection, or which are so complex that they threaten to exhaust the available machine resources. SofCheck Inspector displays preconditions, presumptions, and postconditions in its web-based source listings as a Java comment block immediately preceding the first executable line of the method. if a large number of conditions are found, the display list will be truncated and an ellipsis ("...") substituted for the undisplayed messages. You may display all of the preconditions, presumptions, and postconditions in the bottom pane of the File Source view by clicking on the P/P link at the top of the comment block or on the ellipsis (...) at the bottom of a truncated comment block.
The preconditions displayed by the Inspector are implicit requirements that are imposed on the inputs to a method, as determined by analyzing the algorithms used within the method. Violating preconditions might cause the method to fail or to give meaningless results. During code review, the reviewer can verify that the preconditions determined by the Inspector for the code as written are appropriate, and meet the underlying requirements for the method.
Early in a development cycle, system documentation might be missing or incomplete. Since SofCheck Inspector generates preconditions for each class without requiring that the entire enclosing system be available, it can be used before system integration to understand methods as they are developed. In a mature, maintained codebase the system documentation might no longer agree with current code's behavior. In either case, SofCheck Inspector's generated preconditions can be used to verify both the written and unwritten assumptions made by the codewriters.
Presumptions represent assumptions made by the Inspector about the results of a call on a method whose code is unavailable for analysis. A separate presumption is made for each call site to the unanalyzed method, with a string in the form “@<line-number-of-the-call>” appended to the name of the method. Presumptions do not generally affect the preconditions of the calling routine, but they might influence postconditions of the calling routine.
Postconditions are characteristics of the output which a method could produce, presuming its preconditions are satisfied and the presumptions made about unanalyzed calls are appropriate. Postconditions can help a reviewer understand the purpose and effect of code, even in the absence of other documentation. Likewise, postconditions can be helpful to software developers making use of a method. Comparing postconditions to either preconditions or the context of calling routines can provide valuable insight into the workings of the code which might not be obvious from solely a manual review.
Identify Possible Race Conditions |
top |
SofCheck Inspector detects common forms of race conditions. A race condition may exist if there are two or more concurrent threads that attempt to access the same object, and at least one of them is doing an update. for example, if a Reader thread makes a copy of a List Object at the same time a Writer task is modifying the List Object, the copy of the List Object may be corrupt. Languages such as Java use synchronization or locking as a means to guard against race conditions. SofCheck Inspector identifies race conditions where synchronization is not used or is used incorrectly. (Note that the current release of Inspector does not identify potential deadlocks, also known as deadly embraces, where two threads are stuck waiting on locks held by the other.)
A lock is held during any synchronized method or during any synchronized block of code. Any variable that can be accessed by more than one referencing thread simultaneously must be locked at every reference to guard against race conditions. Furthermore, the referencing lock should match the lock used by other threads to prevent updates during access. If locking is absent, or if one reference uses a different lock than some other reference, SofCheck Inspector identifies a possible race condition. Note that an identified race condition is not guaranteed to create problems on every execution, but it might cause a problem, depending on specific run time circumstances.
Note that if a lock is associated with an object that is newly created each time a method is called, it does not actually provide any synchronization between distinct calls on that method. A lock is only effective if it is associated with an object that is visible to multiple threads. The Inspector essentially ignores locks on objects that are not visible to multiple threads, as they have no synchronizing effect. this means that the Inspector may indicate that there are no locks held at the point of a reference to a potentially shared object, even though there are in fact some local locks held. A future release will identify any potential problems associated with local locks more explicitly.
SofCheck Inspector must understand the threading structure of the program being analyzed to detect race conditions. There are two types of entry points that are important to race condition analysis: Reentrant entry points and Daemon entry points. A Reentrant entry point represents code that can be invoked by multiple threads concurrently. A Daemon entry point (also called a singleton) is presumed to be invoked only by a single thread at a time.
Identify reentrant entry points with the -reentrant "class:method" option on the SofCheck Inspector command line. Use the -daemon "class:method" to identify daemon entry points. See Command Line Invocation above for the syntax for these options. if no -daemon or -reentrant options are specified, SofCheck Inspector uses a default set of entry points for the analysis, based on typical Java and J2EE conventions for multi-threaded applications, servlets, struts Action classes, and JSP pages. SofCheck Inspector recognizes as Reentrant entry points any methods matching
Normally you should specify your own entry points explicitly, unless you have verified that these default entry point patterns will correctly identify all relevant thread entry points.
For partitions that include one or more thread entry points, an indication of zero detected race conditions ensures that there is no path within that partition from one of these entry points to any of the three kinds of unsynchronized access to shared data objects identified by SofCheck Inspector.
SofCheck Inspector performs race condition analysis by default. this helps to ensure that potential race conditions are identified early. Locating race conditions with run-time testing can be difficult given that they normally show symptoms only intermittently, or under heavy load. Note that you may use the -no-race-conditions command line parameter to suppress race condition analysis.
The Race Condition report gives complete details about the shared objects in your program that might be subject to unsafe access. The Race Condition report is divided into three panes. The upper right pane, which runs horizontally, summarizes which methods Inspector has determined are daemon-thread entry points or reentrant entry points. The narrow pane which runs along the left shows the shared objects that might be involved in a race condition. The third pane, which is the large pane taking up the lower right of the report, has a table that summarizes the kinds of race conditions associated with each object, and then provides further information below, reached by clicking on the name of a particular object. For each shared object there is a summary report and a detailed report. The summary report identifies which entry point is associated with each possible race condition. The detailed report goes further by identifying every reference to the object organized by thread entry point, locks held (L1, L2, etc.), and whether it is a read (R) or a write (W) access. A key at the bottom indicates the actual Java object associated with each lock.
As mentioned above, the Inspector only concerns itself with locks that are visible to multiple threads, so an indication of None in the locks held column means no thread-visible locks are held. There may be locks associated with locally created objects, but these provide no effective synchronization between distinct threads.
See Race Condition Messages for details on the messages produced by race condition analysis.
Pragmatic Limitations of static Error Detection |
top |
SofCheck Inspector performs static error detection by holding in main memory a representation of the entire subsystem being analyzed. It is possible that the subsystem being analyzed is so large that its representation cannot be contained in the memory of the host machine on which SofCheck Inspector is running. SofCheck Inspector automatically divides the system under inspection into partitions that are more likely to be analyzable within the memory constraints of the host machine. A user can override this automatic partitioning process by specifying the -global command line option. This will force SofCheck Inspector to perform a global analysis of all of the code identified in the library.
Note that it is more likely that a global analysis might run out of memory during the processing of some source file. In that case, the source file is skipped and analysis proceeds as though that file was not present in the library.
SofCheck Inspector Presumptions |
top |
SofCheck Inspector makes presumptions about the return values and other side effects of unanalyzed method calls. The presumptions of each unanalyzed method call are displayed in the method information block of the calling method. The source line number of the unanalyzed method call is shown after an @ sign, and information about its presumed return value or other side effect is displayed.
The actual unanalyzed call might be directly on the line specified in the presumption (by the @nnn) or it might be a call that occurs inside the method called on the given line. You can tell if it's an indirect call or a direct call by the name given in the presumption. If it doesn't correspond to the name of the method directly called on the given line, then it must be something called indirectly.
Sometimes the presumptions made by SofCheck Inspector are overly "optimistic", such as a given call will never return a null, when in fact it can return a null. For example, suppose that under some circumstances, an unanalyzed method call can return a null, but that the calling method never checks for this possibility, and instead dereferences the return value without checking. This could cause an exception when the program is run, and implies that the program being analyzed contains a latent defect. If the Inspector makes the presumption that the called method does not return null, then it would not identify this latent defect. for this reason, the programmer should check the presumptions about unanalyzed method calls and verify that they are appropriate.
Alternatively, the presumptions made by SofCheck Inspector might be "insufficient". For example the Inspector might presume that some unanalyzed method call could return null, when in fact it never does. Later, in some use of the returned value, far away from the unanalyzed call, the Inspector might complain that a possibly-null value is being dereferenced. The original presumption was insufficient in this case, because it didn't match the actual behavior of the unanalyzed call, and thereby led to the complaint. The programmer can eliminate such a complaint by adding code immediately after the point of the call to assert that the returned value is not null. This will cause the Inspector to tighten up its presumption about the unanalyzed call to satisfy the assertion, and the complaints at other points in the code will go away.
Appendix |
top |
Command Line Invocation |
top |
inspector[.exe] -lib <library-file>
[-all | <name> ...]
[-allow-duplicates]
[-background | -log]
[-baseline]
[-cutoff <inspection_id>]
[-global]
[-messages [ min | normal | max] ]
[ {-daemon "<class>:<method>"} ...
{-reentrant "<class>:<method>"} ... ]
[-output-only]
[-no-race-conditions]
[-no-error-history]
[ [-at-file <directory>] ... @<filename> ... ]
[-repartition]
[-status-codes]
inspector[.exe] [ -help | -v | -version ]
Command Line Options |
top |
Methods are identified by prefixing the name of the method with the name of the class in which the method is defined. Wildcard matching of the string providing the class and method name (via the asterisk character) is available at the beginning or end of the specification, for example: "*class:method(*".
Advanced Command Line Options |
top |
When SofCheck Inspector finishes, it returns a return Code according to the following table. Note: return codes 25 and 29 are not generated unless the -status-codes command line option is given.
return Code |
Description |
0 |
Inspection completed. No errors found. |
25 |
Inspection completed. Some messages were emitted. Note: this return code is generated only if the -status-codes command line option has been given. |
27 |
Input Error. Inspection halted before finishing. |
29 |
Inspector Internal Error. this is most likely due to exhaustion of host memory. Inspection continued with possible omissions. Review the standard output or log file to determine which files were skipped. Note: this return code is generated only if the -status-codes command line option has been given. |
100 |
Inspection Interrupted. Likely cause: the operating system may have terminated the process, as with a "control-C interrupt" or "end process" directive. |
110 |
Database Error. Likely cause: Database corrupted. Please contact Technical Support. |
123 or 124 |
Inspector Internal Error. Inspection halted before finishing. Likely cause: insufficient memory. Please contact Technical Support. |
SofCheck Inspector Library File |
top |
Here is an example of a library file and an explanation of its contents:
OUTPUT_DIR=>
Output_Dir := "JFL.OUTPUT"="jfl.output" ;
DATABASE_DIR=;
Database_Dir := "JFL.DB"="jfl.db" ;
MESSAGE_PATTERNS=;
Message_Patterns := "JFL_MSG_PATTERNS.XML"="jfl_msg_patterns.xml" ;
SOURCE(DIRECTORY=;
Source(Directory => "/HOME/USERID/NET/NEUROTECH"="/home/userid/net/neurotech" ,=, INCLUDE_SUBDIRECTORIES=Include_Subdirectories => true,=true, FILES=Files => ("*.JAVA"=("*.java" ),=), LANGUAGE=Language => TEXT);
SOURCE(DIRECTORY=Text);
Source(Directory => "/HOME/USERID/NET/NEUROTECH"="/home/userid/net/neurotech" ,=, INCLUDE_SUBDIRECTORIES=Include_Subdirectories => true,=true, FILES=Files => ("*.CLASS"=("*.class" ),=), LANGUAGE=Language => JBC);
SOURCE(DIRECTORY=JBC);
Source(Directory => "JFL.ZIP"="jfl.zip" ,=, INCLUDE_SUBDIRECTORIES=Include_Subdirectories => true,=true, FILES=Files => ("*.CLASS"=("*.class" ),=), LANGUAGE=Language => JBC);
Typically, one or more Source directives will specify the JBC (.class) files, and one or more Source directives of Language Text will specify the .java source files from which the .class files were compiled. SofCheck Inspector automatically matches .java files to their corresponding .class files. if a .class file does not have corresponding .java source, inspection messages will be generated in a tabular format, rather than being interspersed into the corresponding Java source. if a .java file does not have corresponding .class files, no analysis can be performed on that file since Inspector reads .class files to determine the semantics of the Java code.
Troubleshooting |
top |
SofCheck Inspector uses the environment variable SOFCHECK_INSPECTOR to determine the location of the program executable installation directory. Certain predefined support files used by Inspector to generate error messages and other documentation are located in the installation directory. if this environment variable is not set correctly, a warning message will be produced and Inspector will terminate. To remedy this problem, make sure that the SOFCHECK_INSPECTOR environment variable is set to the correct value.
We strongly suggest that you familiarize yourself with the file ReleaseNotes.txt, in the SOFCHECK_INSPECTOR installation directory (see above). These release notes contain invaluable tips about both running the Inspector and examining its output; known limitations are also described.
The library file determines which .class files and which source files are available to the Inspector for analysis (see Sofcheck Inspector Library File). if the output produced seems to be missing certain files, check that the library file correctly identifies the directories or jar/zip archives containing the source and .class files, and that "INCLUDE_SUBDIRECTORIES => True" is specified when appropriate. Note that the Files list in a Source directive must be parenthesized, even if there is only one name pattern specified.
Occasionally, due to deeply nested Java source files, Inspector encounters a host limitation on the length of file names created for Inspector's browsable output. For example, the limit on the PC host is 259 characters. In this case an internal error message will be produced which gives the name of the output file that cannot be created. A possible workaround to this problem is to locate the Inspector library closer to the leaves of the source tree so that the file pathname will fit into the 259 character limitation. Please contact Technical Support for further information.
Frequently Asked Questions (FAQ) |
top |
Press the OK button, and you will be allowed to continue running the Console. Be aware that the features of SofCheck Inspector will be limited. Follow the instructions in the dialog box or contact your software reseller to obtain a current license key. If you have a license key and did not install it during the SofCheck INspector installation process, you need can install it by hand by naming it LicenseKey.txt and copying it into the Inspector installation directory e.g. C:\Program Files\SofCheck\Inspector-2.1
Certain Java programs are too large or too complex to analyze within the memory constraints of the host machine. When Inspector detects this circumstance, Inspector will skip analyzing the JVM .class files which are too complex. No annotations or error messages will be generated for these files, and calls to methods which were skipped will be analyzed as though the method body were not available. Detailed information about which files were skipped is available in the “Inspection.log” file.
As an example, certain syntax parsers can be too complex
to analyze within the memory constraints of the host machine.
The parsing routine will typically contain a loop
and deeply nested switch or if-then-else statements
with complex conditional expressions. These can introduce
a very large number of paths and distinct computations
into the program graph, which may bump into the host machine
memory limit.
A future release of the Inspector will make use of
disk-based caching to allow Inspector to handle much
larger systems without partitioning or skipping.
Verify that your paging file size is optimized for your operating system and amount of system memory.
To minimize the likelihood of running out of memory, Inspector automatically breaks large test cases into "partitions," typically of about thirty to fifty thousand lines of code (KLOC) each. The "-global" flag may be used to override this partitioning, in which case you may see more files skipped during the analysis.
You can manually partition your code if you so wish. The separate library files created as part of automated partitioning are preserved in the project directory (with names of the form "part-00X-*.library"), and these may be edited as desired to construct your own partitioning scheme. You can also control automated partitioning by increasing or decreasing the default size of each partition with the "-dbg-partition-limit" command-line flag. Please contact support@sofcheck.com for appropriate use of this option.
These are some of the circumstances where Inspector would find two original source files: it could be that the sources are duplicated because the source file is in a specified directory, and is also in a specified .jar file. Or you might have more than one jar that include the same sources files. Or it could be that there is a test and a release directory with the same sources and both appear in the zip file, etc. A solution could be to be more specific in the library file by adding a few more levels to the path, or removing the source files from the jar, or extracting the sources from the jar files, or combinations of these strategies.
| $Revision: 1.58 $ | top |