At 05:36 AM 25/10/2004 +0000, you wrote:

>Guys, if you remeber me, I have been flooding all the user groups
>related to firebird, with my problem related to firebird using huge
>amount of memory. Now finally I have found the root cause of my
>problem.
>
>It is the udf library 'fbudf', which comes with the firebird
>distribution. BUT there is nothing wrong with the code as such. I
>discovered that when any udf library is linked with 'libfbclient',
>memory is not properly freed up. But then there are some functions in
>fbudf, which require libfbclient (i.e. call to isc_decode_timestamp,
>isc_encode_timestamp etc.). So if you don't link fbudf with
>libfbclient, those functions (addYear) don't respond. Here is what I
>did for fbudf:
>
>1. Copied the source code related to isc_decode_timestamp,
>isc_encode_timestamp and related functions into a new C file.
>
>2. Removed the linking of libfbclient.
>
>3. Linked the new C file with 'fbudf'.
>
>AND guess what? It is running since saturday without a single byte
>increase. Moreover I was amazed to see the low footprint of firebird.
>It is using only 3MB.
>
>The above behaviour can be easily reproduced by linking any udf
>library with libfbclient (even if you don't make any call to the
>libfbclient). Then see the difference in memory usage, after making
>good number of calls to any function in that udf library.

Does this tell you something?

The UDF libraries aren't intended for static linking. They are dynamic
libraries which the *server* loads when a request calls a function in the
module. And the date functions work just fine under the intended model.

It's a pity you didn't mention this earlier, or you could saved yourself
(and several of US) a lot of head-scratching.

./heLen