Leaked objects

Description

Message “Not all objects were released before DeinitializeEngine() call.”

Why does this error message occur in the FREngine log? Are there objects leaked?

Reason

  1. Not all of the objects which were created and used by the application have been deleted before the Engine object deinitialization. Some objects can be incorrectly handled, causing a memory leak. However, after Engine deinitialization all FineReader Engine objects will be deleted in any case, so the memory leak can occur in the client part of the code, i.e. if you create your own wrappers for the FineReader Engine objects and fail to release them before the deinitialization.
  2. The garbage collector did not release the adapters yet and the reference counter is not null.
Solution

Respectively:

    1. If you work with programming languages without garbage collection (for example, C++), you must either use smart pointer classes (see the standard samples in C++ (COM) from the distribution kit) or release objects that were created by creation methods when they are no longer needed. Not released objects are specified in Leaked objects list. 

If all the objects have been deleted, the exception may be caused by the garbage collector operation. If the application is developed in Visual Basic .NET, all objects with the Nothing value are not deleted, they are only marked for deletion. The exact moment when the garbage collector deletes the object is not known. Therefore, you should call the following methods before the deinitialization of the Engine object so that the garbage collector deletes the object:

GC.Collect()
GC.WaitForPendingFinalizers()
    1. Even if you are explicitly calling the garbage collector (GC.Collect), it does not always mean that the objects are deleted immediately. When working in environments with garbage collectors, you can disregard this message.

In platforms with a GC (C#, .NET, Java) it is a diagnostic message. It can be seen when at the moment of FREngine deinitialization the adapters internal objects were already released, for example by the FRDocument.Close call, and then the adapters were still hanged in memory, i.e. the garbage collector did not release them yet. Then after the deinitialization, we can see the reference counter is not null (not all the objects are deleted) but it is impossible to say which one, as the internal objects are already released. A GC can work not always immediately. Sooner or later the GC should work. Internal objects should be released after the deinitialization of the FREngine. So there will not be any memory leak.

Consider using the TotalObjectsCount property of the Engine object which returns the number of unreleased objects and can help you track down the memory leak.

In case these recommendations will not help, please send us the sample project using which such behavior can be reproduced to the Technical Support Team.

Have more questions? Submit a request

Comments

0 comments

Please sign in to leave a comment.