Up
Contents
Search
BullseyeCoverage
Up
Contents
Search
BullseyeCoverage run-time functions may report one of the following error codes to the user or to the file named by environment variable COVERR, if set.
Measurements were successfully written to the coverage file.
The COVFILE environment variable (or COVFILELIST) does not specify the same coverage file
as was used to instrument the object file named in the error message.
You must use the same coverage file at run-time and build time.
Set COVFILE (or COVFILELIST) to the coverage file used to instrument the object files
in the executable reporting this error.
Whenever you copy an instrumented executable to a different computer, also copy the coverage file at the same time.
Under Windows,
after changing the COVFILE or COVFILELIST environment variable,
restart all command prompts and IDEs.
To reduce the likelihood of this error, reuse the same coverage file for each build. There is no advantage to deleting the coverage file before rebuilding.
Coverage files are identified by an ID number.
The error message indicates the missing coverage file (expected-ID).
The error also identifies the file searched (actual-ID),
unless COVFILELIST is set.
BullseyeCoverage version error 2: wrong coverage file. Use same coverage file for building and running. Expected fileId=expected-ID (coverageFileName). Object objectName compileTime (object-ID). Actual fileId=actual-ID path
This error message includes the name of the coverage file coverageFileName used at build-time. This information may be useful if you have not renamed any coverage files after building.
You can determine the cause of this error by looking up the expected-ID in the the log file named below, which is located on the build computer. The content of this log file persists as long as BullseyeCoverage is installed.
| Windows: | %LOCALAPPDATA%\BullseyeCoverage\fileLog
|
| Unix-like system: | $HOME/.BullseyeCoverage/fileLog
|
On Windows, you can use notepad to view the log.
Search for the expected-ID using the menu command Edit Find.
C:\> notepad "%LOCALAPPDATA%\BullseyeCoverage\fileLog"
On Unix-like systems,
you can use more to view the log.
Search for the expected-ID using the / command.
$ more $HOME/.BullseyeCoverage/fileLog
If you find the expected-ID is associated with a filename that occurs again later, then the likely cause of the error is that the missing coverage file was deleted (and then recreated). For example, in the log shown below, the coverage file was overwritten.
2013-01-16 13:07:33 528bc97e /workspace/test.cov covc 2013-01-16 14:06:22 6012dd6f /workspace/test.cov covc
If the expected-ID does not occur in the log, then the likely cause of this error is that some of the code was instrumented on a different account, with a different coverage file.
You can display the file ID of a coverage file with the covmgr command.
For example:
C:\> covmgr -p -f test.cov File-id: 528bc97e
You can enable diagnostic mode so that during building you can see the actual COVFILE environment variable setting,
and verify the path where BullseyeCoverage creates or finds the coverage file.
Run the Coverage Browser and use the menu command Tools Options.
On the Build tab, enable Diagnostic mode.
In your build log, look for lines as shown below:
COVFILE=path fileId=file-ID creating path opening path object objectName object-ID ...
If this error persists, delete all coverage files and do a clean rebuild without BullseyeCoverage. If you see error 2 again, then you did not rebuild everything that was previously instrumented. Do not rebuild with BullseyeCoverage until you have eliminated all previously instrumented code.
The file locking function fcntl returned an error.
The value given by errno= in the error message indicates the operating system error code.
You can look up this error code in your compiler's errno.h header.
The error EDEADLK (errno=35 on Linux) indicates a problem with the file system containing the file named in the error. In particular, file locking implementations for the Network File System (NFS) are known problematic. Relocate the coverage file to the local file system.
The instrumented code contains information about a version of an object file that is not present in the coverage file. This error happens when the coverage file is copied and then modified by instrumenting. It is recommended to maintain one master coverage file for building and instrumenting. Do not overwrite or delete the master. If you make copies of the master for running tests, use covmerge to bring the measurements back, rather than copying and overwriting the master.
Another possible cause of this error is the object file named in the error was overwritten more than 4 times over a period spanning more than 5 days.
Delete all copies of the object file named in the error message, all libraries which might contain the object file, and delete the executable file named in the error message, if any. Then rebuild.
The coverage file is corrupt. Delete the file and then rebuild with coverage build enabled.
The instrumented executable does not match the coverage file. Rebuild the instrumented executable with coverage build enabled.
Function atexit returned an error code.
On Windows, make sure the TMP environment variable specifies a valid, writable directory.
Remove the files BullseyeCoverage*.dll, from this directory.
The auto-save background thread cannot be created. You can either ignore this error, or disable auto-save by setting environment variable COVAUTOSAVE to 0.
Neither the COVFILE nor the COVFILELIST environment variable is set in the context where the instrumented code ran.
Set the COVFILE environment variable to the full path of the
coverage file used to build the project.
These environment variables might be set in the build context but not propagated to the run-time context.
If setting COVFILE in the run-time context proves difficult,
consider using the BullseyeCoverageEnv.txt file described for Unix-like Systems and Windows.
The run-time cannot open the file named by
COVFILE or COVFILELIST.
The file might not exist, or there might be a permission problem opening the file in the context of the instrumented executable.
Set the COVFILE environment variable to the full path of the
coverage file that you used when building
and set the file permissions to allow access from any user.
Set the COVFILE environment variable to the full path of the coverage file used when building.
The coverage file named in the error incorrectly contains no build information.
During instrumentation the coverage file is populated with data identifying sources and functions.
At run-time only the measurements are written.
The coverage file named in the error specifies a file which is
either not a file created by BullseyeCoverage, or was written by an incompatible
version of BullseyeCoverage.
Check that COVFILE specifies the full path of the coverage
file most recently created by BullseyeCoverage when you built the instrumented executable
with coverage build enabled.
No probes have been encountered. There was no instrumented code encountered in the executable image. The code was either never instrumented, or was excluded from measurement. Remove any exclusions. See Integrating With Your Build Process.
The COVNOSAVE environment variable is set to 1. No coverage was saved.
Function cov_write is busy.
Function cov_write returned immediately because a previous caller
in another thread was busy in cov_write
and it was not possible to wait for the previous caller to finish.
Instrumentation data in the .bss (uninitialized data) section is corrupt. The most common cause of this error is the program under test wrote to an erroneous memory address, for example due to a wild pointer or buffer overrun. To diagnose the problem, add calls to cov_check to your program to determine where this error first occurs.
Instrumentation data in the .const (read-only data) section is corrupt. Possible causes of this error are:
cov_dumpData() at various places in your program to see when it first returns this error code.
Continue adding more calls until you narrow down one statement before which cov_dumpData() returns 0 and
after which returns this error code.
The small footprint embedded run-time library configuration cannot open the output
file BullseyeCoverage.data-pid.
The open function returned an improper file descriptor, one of the values 0, 1 or 2.
This error happens when the program under test closed one or more of these reserved file descriptors.
To solve this issue, do not close file descriptor 0, 1, or 2.
The auto-save thread failed to terminate cleanly.
Disable auto-save by setting the COVAUTOSAVE environment variable to 0.
Alternatively, add libcov-noThread.a to your link command and rebuild.
The read function returned failure.
To diagnose i/o failures,
add the function below to your program.
Substitute the actual path of the coverage file for test.cov.
This function demonstrates whether your i/o functions are working properly.
Call this function from various locations in the program, including the very first and last statements.
BullseyeCoverage requires working i/o functions.
It is up to you to resolve any problems this diagnostic function indicates.
#include <fcntl.h>
#include <stdio.h>
#include <unistd.h>
void diag()
{
int fd = open("test.cov", O_RDWR, 0);
if (fd == -1) {
perror("open");
} else {
if (lseek(fd, 0, SEEK_SET) == -1) {
perror("lseek");
} else {
char buf[51];
if (read(fd, buf, sizeof(buf)) < 0) {
perror("read");
} else {
printf("read successful\n");
}
}
if (close(fd) != 0) {
perror("close");
}
}
}
The write function returned failure.
To diagnose this error,
add the function below to your program.
This function demonstrates whether your write function is working properly.
Call this function from various locations in the program, including the very first and last statements.
BullseyeCoverage requires working i/o functions.
It is up to you to resolve any problems this diagnostic function indicates.
#include <fcntl.h>
#include <stdio.h>
#include <sys/stat.h>
#include <unistd.h>
void diag()
{
int fd = open("diag.txt", O_CREAT | O_TRUNC | O_WRONLY, S_IRUSR | S_IWUSR);
if (fd == -1) {
printf("open failed\n");
} else {
if (write(fd, "hello world\n", 12) == 12) {
printf("no errors\n");
} else {
printf("write failed\n");
}
close(fd);
}
}
The lseek function returned failure.
See the diagnostic method for error 29.
The close function returned failure.
See the diagnostic method for error 29.
The run-time was unable to allocate memory.
Updated: 25 Sep 2024
Copyright © Bullseye Testing Technology. All Rights Reserved.