3

We had to use CoFreeUnusedLibrariesEx for fixing a bug with heap not being cleared after using a MSXML library Refer this link: http://blogs.msdn.com/b/marcelolr/archive/2008/11/13/msxml-heaps-not-being-released.aspx

But this caused another issue with TTimers which takes while to show up and disappears when Delphi app is bounced and again shows after a while.

This app uses TTimers to schedule it's job like running a XML transform .

Here is the issue: When TTimer.Enable is called it throws an error not enough Timer available. I know this is a masked error and I would have to figure out how to get to the actual error.

This is a single threaded application with only one timer.

Here are the links I looked into Most Common reason seems to be invalid windows handle https://groups.google.com/forum/#!topic/borland.public.delphi.winapi/UrIskaFZggU

There are other threads that suggested that OS ran out of resources for TIMERS I'm not sure if that is relevant to me.

I'm Just trying to understand what is Interaction between CoFreeUnusedLibrariesEx and TTimers that it gradually some how robs it of resources and makes us bounce the app to get it working.

How do I go about solving this issue , I'm looking for some directions?

user3313541
  • 65
  • 6
  • 1
    Sounds like you are leaking timers. Instrument the apps calls to `SetTimer` and `KillTimer`. – David Heffernan Oct 14 '14 at 13:16
  • 1
    Does that mean CoFreeUnusedLibrariesEx was not affecting it and it was just an existing bug because it showed up right after that change? Let me try Tracking calls to SetTimer and KillTimer thanks! – user3313541 Oct 14 '14 at 13:26
  • Very hard to know what's going on. I'm just telling you what it sounds like from here. I could be way off base. – David Heffernan Oct 14 '14 at 13:34
  • Hi David, I've been looking around and I'm not sure how to do this.I'm on Delphi 5 and in our implementation we initialize TTimer as a class vraible and after that just Enable or Disable it. Does enabling and Disabling recreate a TTImer? – user3313541 Oct 14 '14 at 18:46
  • Yes, it does. Are you leaking timers by any chance? – David Heffernan Oct 14 '14 at 18:49
  • I'm sorry I'm not familiar with this. How do I figure out if it's leaking ...I couldn't Look at setTimer and KillTimer ,I work on textfiles as we don't have IDE's for this. Could you please point me to a link ,I couldn't find an event Listener to call me whenever SetTimer or KillTimer is called? – user3313541 Oct 14 '14 at 18:55
  • It kind of depends what else is going on in this app of yours. The entire process shares resources. What other modules are creating timers? – David Heffernan Oct 14 '14 at 18:56
  • we only have this module creating TTimers ,I couldn't find it anywhere else. – user3313541 Oct 15 '14 at 16:02

1 Answers1

1

CoFreeUnusedLibrariesEx should not affect TTimers. But if loading and unloading a (buggy) dll leaks any user objects (this includes timers, window handles, ...) then I could imagine that you run out of user objects.

Use Windows Task Manager and configure it so it will show the "USER Objects" in the "Processes" tab. Then compare the number of user objects when you call CoFreeUnusedLibrariesEx and when you don't call CoFreeUnusedLibrariesEx.

Sebastian Z
  • 4,520
  • 1
  • 15
  • 30
  • Nice let me try this out ,will get back to you – user3313541 Oct 14 '14 at 18:48
  • I gave this a try and UserObjects after call to CoFreeUnusedLibrariesEx go up ,trying without it UserObjects returned to normal ,but with CoFreeUnusedLibrariesEx UserObjects that the APP uses always goes up. How is this call eating up user objects? – user3313541 Oct 15 '14 at 16:04
  • hmm ..Looks like you might have already answered that Loading and unloading buggy dll causes this.How can I remedy this situation ,Figure out where the leak is in the buggy dll? – user3313541 Oct 15 '14 at 16:10
  • If you can reproduce the leak with LoadLibrary and UnloadLibrary, then the leak must be somewhere in dllmain (or initialization/finalization in Delphi) of the dll. And it is likely that the dll is doing [something "scary"](http://stackoverflow.com/questions/5834508/usage-limitations-during-the-dllmain-attach-and-detach-process) in the initialization. If you don't have the source of the dll, then you'll need to ask the creator of that dll to fix his code. – Sebastian Z Oct 15 '14 at 16:39
  • I'm going to accept this as an answer as I wanted to understand what was going on, this is a reasonable explanation at least for me. – user3313541 Oct 15 '14 at 17:19