L&L leaks (class clsLLXLibraryProxy)?

English Forum
1

Hi,
upon exiting our application it always print this line in the debug output:

class clsLLXLibraryProxy: undeleted objects, count=4

Does it means we have some L&L leak? If yes, can I somehow find out which objects are leaking? Debwin doesn’t show any leads.

We’re using L&L 22, Windows 7 Pro.

Thank you

2

Can you check whether LlJobClos is called on time? We suspect that the job may be closed very late. Please try to call LlJobClose earlier, e.g. when closing the form.

3

Thanks for the reply,
yes, job is closed on time. That is, when preview/print is closed, job is also closed. We also don’t use any L&L “preloading”.

I want to mention that we’re using ILLDataProvider in C++. Maybe there could be the problem.

4

The four objects don’t sound too dramatic to me - if this number doesn’t increase with the number of prints. Memory will be released during shutdown anyway. If you want to make sure feel free to post a log file here or get in touch with support - we might need a sample as we cannot reproduce this debug output here.

5

Yes, the count is always 4. So I will not investigate it further then.

Just one more question. I’m setting the cmll22.dll as delay loaded DLL. Setting it also for delay unload doesn’t work. Is it even supported by L&L? I was thinking that maybe tha “four objects” mentioned above prohibited the delay unload.

Thanks

6

It’s possible that this is related - the question is when the DLL should be unloaded again. If you are using C++, …
__FUnloadDelayLoadedDLL2("cmll22.dll");
…should be called, according to this documentation.

7

Yes, I’m calling it after the LlJobClose().

8

So I made a simple test case, calling only LlJobOpen() an LLJobClose() and it is the same.

Maybe there are some internal static objects or something. Anyway, given that delayed DLL loading is working ok, delayed unloading isn’t a big problem for us as we can cases where the memory usage is critical solve by other means.

1 Like
9

Thanks Jozef - we’ll try to reproduce this with LL25 anyway, however I figure it’s not a problem for you. Feel free to come back if you’d like us to investigate this any further.