You are here: Start » Technical Issues » Troubleshooting

Troubleshooting

This article describes the most common problems that might appear when building and executing programs that use FabImage Library.

Problems with Building

error LNK2019: unresolved external symbol _LoadImageA referenced in function
error C2039: 'LoadImageA' : is not a member of 'fil'

The problem is related to including the "windows.h" file. It defines a macro called LoadImage, which has the same name as one of the functions of FabImage Library. Solution:

  • Don't include both "windows.h" and "FIL.h" in a single compilation unit (cpp file).
  • Use #undef LoadImage after including "windows.h".

error LNK1123: failure during conversion to COFF: file invalid or corrupt

If you encounter this problem, just disable the incremental linking (properties of the project | Configuration Properties | Linker | General | Enable Incremental Linking, set to No (/INCREMENTAL:NO)). This is a known issue of VS2010 and more information can be found on the Internet. Installing VS2010 Service Pack 1 is an alternative solution.

Exceptions Thrown in Run Time

Exception from the fil namespace is thrown

FabImage Library uses exceptions to report errors in the run-time. All the exceptions are defined in fil namespace and derive from fil::Error. To solve the problem, add a try/catch statement and catch all fil::Error exceptions (or only selected derived type). Every fil::Error object has the Message() method which should provide you more detailed information about the problem. Remember that a good programming practice is catching C++ exceptions by a const reference. 

    try 
    {
        // your code here
    }
    catch (const ftl::Error& er)
    {
        cout << er.Message();
    }

High CPU Usage When Running FIL Based Image Processing

When working with some FIL image processing functions it is possible that the reported CPU usage can reach 50~100% across all CPU cores even in situations when the actual workload does not justify that hight CPU utilization. This behavior is a side effect of a parallel processing back-end worker threads actively waiting for the next task. Although the CPU utilization is reported to be high those worker threads will not prevent other task to be executed when needed, so this behavior should not be a problem in most situations.

For situations when it is not desired this behavior can be changed (e.g. when profiling the application, performance testing or in any situation, when high CPU usage interfere with other system). To block the worker threads from idling for extended period of time the environment variable OMP_WAIT_POLICY must be set to the value PASSIVE, before the application is started:

    set OMP_WAIT_POLICY=PASSIVE

This variable is checked when the DLLs are loaded, so setting it from the application code might not be effective.

Previous: Processing Images in Worker Thread Next: Memory Leak Detection in Microsoft Visual Studio