Skip to content

Appendix D. Known issues#

Overall known issues#

Warnings during the compilation of user code that utilizes the SDK libraries#

For example:

warning: 'fsdk::IQualityEstimator' has virtual functions but non-virtual destructor [-Wnon-virtual-dtor]
        struct IQualityEstimator : IRefCounted {

This is a normal and expected behavior. For details, see Core Concepts - Reference Counted Interface.

Premature end of JPEG file#

Sometimes you can meet such a log:

[Error] [Image] FreeImage error: format=1, msg=Premature end of JPEG file.

This issue occurs if your JPEG file was not previously recorded or saved properly. You can find more information on this error on the Internet. Fortunately, this error is not fatal and you can continue working with the image and get valid detection, landmarks and warped image. You can also try to re-save this image.

SDK stuck when run sdk algorithm in separate process after root FaceEngine object initialized#

For example:

void simpleDetect(const fsdk::Image& image, const fsdk::IDetectorPtr& faceDetector) {
    fsdk::ResultValue<fsdk::FSDKError, fsdk::Face> result = faceDetector->detectOne(
            image,
            image.getRect(),
            fsdk::DetectionType::DT_BBOX
    );
}

int main()
{
    auto resFaceEngine = fsdk::createFaceEngine("./data");
    fsdk::IFaceEnginePtr faceEngine = resFaceEngine.getValue();

    fsdk::ILicense* license = faceEngine->getLicense();
    fsdk::activateLicense(license, "./data/license.conf");

    fsdk::Image image;
    const string imagePath {"image_720.jpg"};
    image.load(imagePath.c_str(), fsdk::Format::R8G8B8);

    auto detRes = faceEngine->createDetector(fsdk::FACE_DET_V3);
    fsdk::IDetectorPtr faceDetector = detRes.getValue();

    // Run detection in separate process
    pid_t ch_pid = fork();
    if (ch_pid == -1) {
        perror("fork");
        exit(EXIT_FAILURE);
    } else if (ch_pid > 0) {
        cout << "spawn child with pid - " << ch_pid << endl;
    } else {
        simpleDetect(image, faceDetector);
    }

    pid_t child_pid;
    while ((child_pid = wait(nullptr)) > 0)
        cout << "child " << child_pid << " terminated" << endl;

    return 0;
}
Cause deadlock. This behaviour observed since sdk version 5.4 and above. The problem can be solved if you make all forks before creating the FaceEngine object. More reading in Best practices

Undefined behaviour with multithreaded usage of the FaceEngine and algorithms#

Creation and destroying Luna SDK algorithms from the different threads is prohibited due to internal implementation restrictions. In such case undefined behaviour is possible - segmentation faults or invalid results. More reading in Best practices

Floating point exceptions when working with images that have GPU memory residence#

If you're getting floating point exceptions when using images with GPU memory residence please make sure that Luna SDK runtime has been initialised with at least 2 worker threads. For more info about runtime configuration please refer to Runtime settings chapter in ConfigurationGuide handbook.

Coordinate differences for batched detections#

It is possible to obtain some small differences in detected image boxes and landmarks for different placement of images within batches, when the sizes of different images are close to each other. This note is correct for all detector types, including face detectors, human detectors, face+human detectors etc.

CentOS 8 known issues#

Archive unpacking#

We have detected such behavior on CentOS 8.

unzip *.zip;
error: invalid zip file with overlapped components (possible zip bomb)

while unpacking archives. The bug is caused by unzip-6.0-45.el8 package. We recommend to downgrade it:

rpm -q unzip-6.0-45.el8 && yum remove unzip && yum install unzip-6.0-44.el8

Possible content of test.xcent:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

    <key>com.apple.security.get-task-allow</key>

    <true/>

</dict>

</plist>

Astra Linux known issues#

Startup error#

Applies to LUNA SDK v.5.26.0 and earlier.

This section provides a step-by-step guide to resolving the issue with the execstack tool, using the FingerprintViewer application as an example.

The FingerprintViewer application has compatibility issues on Astra Linux because some LUNA SDK shared libraries have the executable stack flag. This flag causes issues on secure operating systems like Astra Linux, which do not allow executable stacks by default.

To fix this, you can remove the executable stack flag from the affected libraries using the execstack tool:

1. Install execstack.

Astra Linux does not include execstack in its standard repositories. To obtain it, you can download the .deb package from Debian's official repository.

1.1. Download the package:

wget http://ftp.ru.debian.org/debian/pool/main/p/prelink/execstack_0.0.20131005-1+b10_amd64.deb

Example output:

--2025-03-03 11:09:39--  http://ftp.ru.debian.org/debian/pool/main/p/prelink/execstack_0.0.20131005-1+b10_amd64.deb
Resolving ftp.ru.debian.org (ftp.ru.debian.org)... 85.143.112.112
Connecting to ftp.ru.debian.org (ftp.ru.debian.org)|85.143.112.112|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 88380 (86K) [application/octet-stream]
Saving to: ‘execstack_0.0.20131005-1+b10_amd64.deb’

execstack_0.0.20131005-1+b10_amd64.deb   100%[================================================================>]   86.31K  --.-KB/s    in 0.003s  

2025-03-03 11:09:39 (28.6 MB/s) - ‘execstack_0.0.20131005-1+b10_amd64.deb’ saved [88380/88380]

1.2. Install the package:

sudo apt install ./execstack_0.0.20131005-1+b10_amd64.deb

Example output:

Reading package lists... Done
Building dependency tree
Reading state information... Done
Note, selecting 'execstack' instead of './execstack_0.0.20131005-1+b10_amd64.deb'
execstack is already the newest version (0.0.20131005-1+b10).
Updated 0 packages, installed 0 new packages, marked 0 for removal, and left 0 unchanged.

2. Identify libraries with executable stack flags.

2.1. Navigate to the directory containing the LUNA SDK shared libraries being used. For example:

cd ~/luna-sdk_astra_se_rel_v.X.X.X/lib/gcc4/x64

2.2. Run the execstack command to check for libraries with the executable stack flag:

execstack *

Libraries marked with X have the executable stack flag set and require modification:

- libcublasLt.so
- libcublasLt.so.11
- libcublasLt.so.11.6.5.2
- libcublas.so
- libcublas.so.11
- libcublas.so.11.6.5.2
- libcudnn_cnn_infer.so
- libcudnn_cnn_infer.so.8
- libcudnn_cnn_infer.so.8.9.0
- libcudnn_ops_infer.so
- libcudnn_ops_infer.so.8
- libcudnn_ops_infer.so.8.9.0
- libcudnn.so
- libcudnn.so.8
- libcudnn.so.8.9.0
X libFaceEngineSDK.so
X libFaceEngineSDK.so.5
X libFaceEngineSDK.so.5.23
X libflower.so
- libLivenessEngineSDK.so
- libLivenessEngineSDK.so.1
- libLivenessEngineSDK.so.1.0
- libMatchingKernel.so
- libMatchingKernel.so.0
- libMatchingKernel.so.0.0
X libTrackEngineSDK.so
X libTrackEngineSDK.so.0
X libTrackEngineSDK.so.0.0
X libvlTracker.so

3. Remove executable stack flags.

For each library marked with X, use the execstack tool to clear the executable stack flag:

execstack -c <library_name>

Example commands:

execstack -c libFaceEngineSDK.so
execstack -c libFaceEngineSDK.so.5
execstack -c libFaceEngineSDK.so.5.23
execstack -c libflower.so
execstack -c libTrackEngineSDK.so
execstack -c libTrackEngineSDK.so.0
execstack -c libTrackEngineSDK.so.0.0
execstack -c libvlTracker.so

4. Verify changes.

After clearing the flags, verify that all shared libraries are free of the executable stack flag:

execstack *

Expected output after fixing:

- libcublasLt.so
- libcublasLt.so.11
- libcublasLt.so.11.6.5.2
- libcublas.so
- libcublas.so.11
- libcublas.so.11.6.5.2
- libcudnn_cnn_infer.so
- libcudnn_cnn_infer.so.8
- libcudnn_cnn_infer.so.8.9.0
- libcudnn_ops_infer.so
- libcudnn_ops_infer.so.8
- libcudnn_ops_infer.so.8.9.0
- libcudnn.so
- libcudnn.so.8
- libcudnn.so.8.9.0
- libFaceEngineSDK.so
- libFaceEngineSDK.so.5
- libFaceEngineSDK.so.5.26
- libflower.so
- libLivenessEngineSDK.so
- libLivenessEngineSDK.so.1
- libLivenessEngineSDK.so.1.0
- libMatchingKernel.so
- libMatchingKernel.so.0
- libMatchingKernel.so.0.0
- libnppc.so
- libnppc.so.11
- libnppc.so.11.4.0.110
- libnppicc.so
- libnppicc.so.11
- libnppicc.so.11.4.0.110
- libnppidei.so
- libnppidei.so.11
- libnppidei.so.11.4.0.110
- libTrackEngineSDK.so
- libTrackEngineSDK.so.0
- libTrackEngineSDK.so.0.0
- libvlTracker.so

All libraries should now display a - instead of X, indicating that the executable stack flag has been successfully removed.

5. Test FingerprintViewer.

After completing the above steps, launch the FingerprintViewer application. If the issue was caused by the executable stack flag, the application should now start without errors.