Error Messages of ctcpost

When reports are generated with the postprocessor ctcpost, error and warning messages are written to stderr. Also, an exit value 1 is returned whenever postprocessor execution is aborted by an error.

List of error messages

0: Configuration parameter PARAM has illegal value VALUE: The parameter PARAM is either set in a configuration file (ctc.ini), or by the command-line option -C PARAM=VALUE. With option -V for ctcpost, you can show the configuration files used to correct this definition.
1: Bad configuration format PARAM in file filename at line N: PARAM is not a valid configuration parameter. If no file is specified, it is probably set for the command-line call directly.
2: Bad data file filename: The specified datafile is corrupted. Check if it is actually a datafile from the test runs.
3: Bad identification stamp in file filename: The specified symbolfile or datafile is corrupted, or has been created with some non-compatible version of Testwell CTC++.
4: Incompatible number format in file filename: The specified symbolfile or datafile is corrupted. Perhaps it is not written by Testwell CTC++.
5: Error in symbol file filename: There is a problem in symbolfile filename. Perhaps it is corrupted. You can try and delete the file and do the instrumentation again.
6: Cannot close file filename: reason: File filename could not be closed.
8: Cannot create file filename: reason: File filename could not be created.
9: Erroneous command line, description: The ctcpost command line options are used or combined in a wrong way. Check The Postprocessor ctcpost for the three different functions of ctcpost and their command-line options.
10: License problem: description: No license could be checked out for this ctcpost run. The description from Flexera's licensing software gives more details about the problem. You can also check with ctc -V which licenses are generally available.
11: Internal error: Some internal error detected in ctcpost.
12: Missing definition PARAM in configuration file: The mandatory configuration parameter PARAM is missing in the configuration files consumed. You can check with option -V which configuration files are used. As all mandatory parameters are set in the configuration files delivered with Testwell CTC++, a whole file might have been deleted. Check for example if there is still a ctc.ini in CTCHOME.
14: Cannot open file filename: reason: File filename could not be opened.
15: Out of memory: Some internal processing in ctcpost requiring heap space had failed.
16: Cannot read file filename: reason: File filename could not be read.
17: Cannot write file filename: reason: Writing of file filename failed.

List of notice messages

The notice messages give additional information about the execution of ctcpost to the user. They are written to stderr in situations described below. Additionally, an extra header line, like

*** 7 verbose notice(s) written to stderr

is written to the report.

Different (+newer) instrumentation for a file filename in symbol file symbolfile encountered (overrides the previous).

Two or more symbolfiles have been input to ctcpost. For the source file specified, two descriptions exist. The newer description from symbolfile is used.

Different (+older) instrumentation for a file filename in symbol file symbolfile encountered (discarded).

Two or more symbolfiles have been input to ctcpost. For the source file specified, two descriptions exist. The older description from symbolfile is discarded.

Different (+older | +newer) counter data for file filename coming from datafile datafile (discarded).

The fingerprint for source file filename from datafile does not match the fingerprint from the symbolfile. Possible reasons are:

The instrumented binary under test and the symbolfile(s) do not represent the same instrumentation (the same version of the source code). In this case, "+older" indicates that an old version of the binary was tested, and "+newer" indicates that the binary is newer, i.e. the symbolfile(s) are from a former instrumentation.
An existing datafile written by a different version of the binary has been used during test on purpose. If the source file was changed and has not been tested at all in this test run, ctcpost sets its counters back to zero. Everything is ok in this case.

Counter data for an unknown file filename encountered coming from datafile datafile (discarded).

The source file filename is not represented in the input symbolfiles for this ctcpost call. Hence its coverage data is not used. Check if a symbolfile is missing.

Counter data for file filename encountered coming from datafile datafile, file identifications are same but counter array sizes not (discarded).

This is an internal sanity check that certain data structures in symbolfile, in datafile or in memory are not corrupted.

Header file filename included at or via source file sourcefile is different from what it was when it was extracted previously (this header file was not extracted).

Instrumented header files, included in many source files, are shown as one entity in the reports. Counter data is added up. This works as long as the code representation of the header is the same in all source files. If that is not the case (for example, by the use of different #DEFINE content), the first version of the header found is reported as an entity ("extracted"). All different versions processed later are reported as a part of their including source file. This is the case for the header specified included in the source file specified.