I've found something interesting about FreeUDFLib in MERS' home page, this article says that FreeUDFLib.dll could bring problems in IB 6.0. (The article is at the bottom of this e-mail)

I was wondering if any of you had this problem how did you deal with it (since those UDFs are very useful and we wouldn't like to stop using them). Also i've been wondering if this is applies for Firebird too.


Luciano.

Subject: IB 6 vs. FreeUDFLib.dll
Author: "pcdata" <myname@...>
Date: Mon, 29 Oct 2001 17:02:32 +0100
Newsgroup: borland.public.interbase.general




------------------------------------------------------------------------------

The problem was not only the FREE_IT option in the declaration of the UDF in the database, and consequently building a new FreeUDFLib.dll to enable the FREE_IT compiler directive in order to work (i wonder why they have disabled this by default), but we had to get rid of the function we used and we decided not to use FreeUDFLib.dll anymore in combination with Interbase 6 due to the following article we found on internet. Final conclusion one could draw after reading this article is: do NOT use FreeUDFLib.dll with IB 6 !!!

memory Management Issues
--------------------------------------------

memory management issues deal more with memory leaks than server crash problems.. However, as we all know InterBase doesn't do very well when the system is low on memory. In fact, InterBase will often crash when the operating system says no more memory. So, it is advantageous to understand the memory management issues when developing UDFs for InterBase.

Dynamic memory allocation
On Windows platforms there isn't a standard memory allocation function. Each compiler implements its own memory management functions. There also isn't any standard for how to implement memory management. Because of this you cannot mix and match your memory management calls. If you allocate memory with one compiler's allocation function, you must free the memory with that same compiler's deallocation function. You can't, for instance, allocate memory with MicroSoft Visual C++'s allocation function and free it with a Borland compiler's deallocation function.

InterBase v5.x is compiled with MSVC++ (don't ask), and we make use of the memory management functions provided by MSVC++. This means that all InterBase memory allocation and deallocations must be with the MSVC++ memory management functions.
This causes a problem for certain types of UDFs that are written with a Borland compiler (BC++, Delphi, or C++ Builder). UDFs that dynamically allocate memory for return parameters and specify the FREE_IT keyword are subject to memory leaks. The FREE_IT keyword specifies that the memory associated with the return parameter should
be freed by InterBase when it is done with it. This causes a problem for InterBase when the memory is dynamically allocated using a Borland compiler. InterBase cannot free the memory, because it wasn't allocated by MSVC++'s memory allocation function.
What it boils down to is the fact that InterBase and the UDF are using different pools to draw memory from. InterBase, using MSVC++ memory management functions, doesn't have access to the pool of memory being used by the UDF. So, everytime the UDF is called it will allocate a chunk of memory that is never freed, but all references to it are released.
This causes a memory leak and bloat the ibserver.exe process. This memory will not be freed until the ibserver.exe process is stopped and restarted.
------------------


[Non-text portions of this message have been removed]