Corrupt file causes LoadMemory to load/unload DLLs and later access violate

We are having an issue with LMemoryFile::LoadMemory in the Raster Imaging Pro 14 library. I know this is a very out-of-date version but we have not had the need to upgrade yet, and wouldn't know if a later version would solve this problem anyway..

We are trying to load some preview images with the following code (after initialising LeadTools):

void LoadFromMemory(void *imageData, unsigned imageSize)
{
   LBitmap lBitmap(128, 128, 32, ORDER_BGR, NULL, TOP_LEFT, 0, TYPE_CONV);
   LMemoryFile memFile(lBitmap);
   LBuffer leadBuffer(imageData, imageSize);

   if (memFile.LoadMemory(leadBuffer, 0, ORDER_BGR, LOADFILE_ALLOCATE | LOADFILE_STORE, NULL) == SUCCESS)
   {
      // success
   }
   else
   {
      // failed
   }   
}

This all works fine if a valid JPG is used and looking at the EventLog (in Borland) shows that only the LeadTools DLLs required for the type of file being read are loaded. However, if a corrupt file (a JPG in this case) is used then LoadMemory results in lots of DLLs being loaded and unloaded consecutively, each one corresponding to a different file type. I assume it is trying to identify what type of file the corrupt one is.

After this has happened it seems that LeadTools will always throw an access violation when any of the threads which have used the library (we are multi-threading) close. The problem is that the main thread should still have all the DLLs loaded but it seems that the failed image load has unloaded some, which are then (maybe) tried to be unloaded again when the thread closes.

Any idea why the DLLs are being unloaded when a corrupt file is read and if LeadTools is thread-safe in this way?

Thanks.

The behavior you described appears to be normal, but you can modify it.

When our LtFil14n DLL tries to determine the format of an image you tried to load, it will use various 'filter' DLLs, such as LfCmp14n, LfTif14n, lfBmp14n, etc. until either one of them succeeds, or they all fail to load the image.

Most of the 'filter' DLLs are thread-safe, except for a few that depend on third-party modules.

I suggest that you deploy our DLLs in the same folder that has your application's EXE and not put any of them in the system PATH, and make sure to only deploy the minimum number of DLLs needed for your application. This means do not deploy any LF*.DLL filters unless you need that particular format.

In any case, I'd like to send you the latest v14 dlls. Please send an email to support@leadtools.com in order to get the download instructions for the latest patch.  For verification purposes, I need you to include the following information:
 
1. The company you work for
2. The LEADTOOLS serial number(s) you own.
3. The name(s) of the developer(s) using the serial number
4. A link to this forum post.
___________________________________
Maen Badwan
LEADTOOLS Technical Support