Skip to content

Appendix D. Known issues#

Overall known issues#

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 known issues#

CentOS 7#

Archive unpacking#

We have detected such behavior on CentOS 7.

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

while unpacking archives. The bug is caused by unzip-6.0-22.el7_9 package. We recommend to downgrade it

rpm -q unzip-6.0-22.el7_9 && yum remove unzip && yum install unzip-6.0-21.el7

CentOS 8#

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

MacOS known issues#

Signing#

This section describes problems that may occur after building and executing one of the examples from the root directory and provides possible solutions for their solving.

For example, a problem may occur while building the following example:

./build/example_extraction/example_extraction

Possible problem:

zsh: killed     ./build/example_extraction/example_extraction

Solution: sign your binary file by your apple development profile or using test.xcent entitlements:

$ codesign -v --force --sign - --entitlements test.xcent build/example_extraction/example_extraction

Possible problem:

$ build/example_extraction/example_extraction: replacing existing signature
build/example_extraction/example_extraction: errSecInternalComponent

Solution: In this case please refer to https://stackoverflow.com/questions/24023639/xcode-command-usr-bin-codesign-failed-with-exit-code-1-errsecinternalcomponen

$ security unlock-keychain login.keychain

It may be also required to re-sign all libraries:

$ codesign -v --force --sign - --entitlements test.xcent --timestamp=none lib/clang/x64/lib*

Possible problem:

$ lib/clang/x64/libFaceEngineSDK.dylib: replacing existing signature
$ lib/clang/x64/libFaceEngineSDK.dylib: the codesign_allocate helper tool cannot be found or used

Solution:

$ cp lib/clang/x64/libFaceEngineSDK.dylib lib/clang/x64/libFaceEngineSDK.dylib1
$ codesign -v --force --sign - --entitlements test.xcent lib/clang/x64/libFaceEngineSDK.dylib1
$ mv lib/clang/x64/libFaceEngineSDK.dylib1 lib/clang/x64/libFaceEngineSDK.dylib

On success, the following response will be returned:

$ codesign -v --force --sign - --entitlements test.xcent lib/clang/x64/lib*

Result:

$ lib/clang/x64/libBestShotMobile.dylib: replacing existing signature
$ lib/clang/x64/libBestShotMobile.dylib: signed Mach-O thin (arm64) [libBestShotMobile]
$ lib/clang/x64/libFaceEngineSDK.dylib: replacing existing signature
$ lib/clang/x64/libFaceEngineSDK.dylib: signed Mach-O thin (arm64) [libFaceEngineSDK]
$ lib/clang/x64/libLivenessEngineSDK.dylib: replacing existing signature
$ lib/clang/x64/libLivenessEngineSDK.dylib: signed Mach-O thin (arm64) [libLivenessEngineSDK]
$ lib/clang/x64/libTrackEngineSDK.dylib: replacing existing signature
$ lib/clang/x64/libTrackEngineSDK.dylib: signed Mach-O thin (arm64) [libTrackEngineSDK]
$ lib/clang/x64/libflower.dylib: replacing existing signature
$ lib/clan$ g/x64/libflower.dylib: signed Mach-O thin (arm64) [libflower]
$ lib/clang/x64/libtbb.dylib: replacing existing signature
$ lib/clang/x64/libtbb.dylib: signed Mach-O thin (arm64) [libtbb]

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>

Jetson known issues#

Jetson Nano#

The launch timed out and was terminated#

During running sdk tests with big batches, algorithm execution stuck with error "The launch timed out and was terminated" returned by cuda runtime. Launch timeouts normally occur because the kernel is taking too long to run on a GPU which has an active display or enabled kernel timeout debug option as jetson nano does by default in comparison to Jetson TX2. It's safety mechanism to prevent the screen from freezing. The driver will kill kernels taking more than 5 seconds (nano default) to complete. As a last resort, you can refer for workaround in official nvidia FAQ, but it's not recommended.