Welcome Guest! To enable all features, please Login or Register.



Last Go to last post Unread Go to first unread post
#1 Posted : Wednesday, May 2, 2012 10:58:02 PM(UTC)


Groups: Registered
Posts: 4

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
      // 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?



Try the latest version of LEADTOOLS for free for 60 days by downloading the evaluation: https://www.leadtools.com/downloads

Wanna join the discussion? Login to your LEADTOOLS Support accountor Register a new forum account.

#2 Posted : Thursday, May 3, 2012 3:35:32 AM(UTC)
Maen Hasan

Groups: Registered, Tech Support
Posts: 1,326

Was thanked: 1 time(s) in 1 post(s)

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
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Powered by YAF.NET | YAF.NET © 2003-2023, Yet Another Forum.NET
This page was generated in 0.065 seconds.