--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:

>
> At 03:52 PM 30/11/2007, you wrote:
>
> >>
> >> >I am using the FreeAdhocUDF which can be downloaded from
> >> >http://www.udf.adhoc-data.de/index_eng.html
> >> >
> >> >We've tested the latest version. We found that after UDF calls, the
> >> >memory was not released until the connection to database is closed.
> > > 2. what your declaration of the UDF looks like.
> >
> >DECLARE EXTERNAL FUNCTION F_STRINGLENGTH
> > CSTRING(254)
> > RETURNS INTEGER FREE_IT
> > ENTRY_POINT 'stringlength' MODULE_NAME 'FreeAdhocUDF';
>
> This is the wrong declaration for a function that passes a string

and returns an integer. The return value never gets lifted off the
stack. (FREE_IT is used to release memory that has been allocated by
the UDF for a *returned* string...)

>
> It should look more like this (without testing, because I can't at

the moment):

>
> DECLARE EXTERNAL FUNCTION F_STRINGLENGTH
> CSTRING(254)
> RETURNS INTEGER BY VALUE
> ENTRY_POINT 'stringlength' MODULE_NAME 'FreeAdhocUDF';
>
> or
>
> DECLARE EXTERNAL FUNCTION F_STRINGLENGTH
> CSTRING(254),
> INTEGER
> RETURNS parameter 2
> ENTRY_POINT 'stringlength' MODULE_NAME 'FreeAdhocUDF';
>
> Also make sure that the number of BYTES in the string that you are

passing TO the UDF is not larger than the declared 254 bytes. (You
can make multiple declarations of the same UDF, using different
external names, if you need to declare a bigger input parameter to
accommodate more bytes.)

>
> If you got this declaration from an SQL script supplied by the

authors of the UDF library, you had better alert them to the mistakes.
Your problem could also be hiding an error in the UDF code that is
causing strings not to be cleaned up in a thread-safe manner.

>
> You could alternatively use Firebird's own STRLEN() function (in

ib_udf) to be on the safe side.

>
> ./heLen
>

First, I got the declaration form the SQL script supplied by the
author of the UDF library.

Second, I have tried these 2 declarations:

DECLARE EXTERNAL FUNCTION F_STRINGLENGTH
CSTRING(254)
RETURNS INTEGER BY VALUE
ENTRY_POINT 'stringlength' MODULE_NAME 'FreeAdhocUDF';

DECLARE EXTERNAL FUNCTION F_STRINGLENGTH
CSTRING(254),
INTEGER
RETURNS parameter 2
ENTRY_POINT 'stringlength' MODULE_NAME 'FreeAdhocUDF';

The problem didn't go away.

Perhaps this was the problem with UDF, my configuration problem or
operation mistake. Or perhaps the new release of Firebird has already
fix the problem.

What I could see is that fbserver.exe got 140M memory usage increased
and totally 500M system memory usage increased every time after
executing stored procedure.

Sorry to bother you.