re-use of dbprocess structure (was: Re: [freetds] state ofdbrpcsend())

liam at liam at
Fri Jul 9 08:53:19 EDT 2004

On Fri, Jul 09, 2004 at 12:54:11PM +0200, ZIGLIO, Frediano, VF-IT wrote:

> What do you mean by "96-120 bytes per 1000 iterations" ?

I execute 1,000 interations of the call_sp() function that I mentioned 
in my previous post in a 'for' loop. That is:

        void call_sp(db_ctx *ctx, int blah) {

                dbrpcinit(ctx->dbproc, ..., 0);
                while (dbresults() != NO_MORE_RESULTS) {
                        /* dbbind points to stack variables only */
                        while (dbnextrow() != NO_MORE_ROWS) {
                                /* process bound variables */
                if (dbhasretstat() == TRUE) {
                        ret = dbrestatus(ctx->dbproc)
                        /* do stuff here */

	for (x = 0; x < 1000; x++) {
		call_sp(ctx, x);

If I set the upper bound of the loop to 10, I see no memory growth. If I 
set the upper bound of the for loop to 1000, I see ~100 bytes of memory 
growth. This growth increases linearly as the upper bound of the 
interations grows.

> Or did just you try with 1000 iterations and you got 100 bytes of leak?
> You have to keep in mind that system libraries (glibc, nss modules and
> so on) sometimes allocate some bytes never freed (an example in Linux
> seems gethostbyname).

True. However, the process should not grow without bound. The dblib
RPC APIs should not need to call gethostbyname() or any other such functions 
that have internal static data storage inside the call_sp() function 
as a single database connection has already been pre-setup.

The program should reach a steady-state of memory allocation if it is
just calling call_sp() over and over again and doing nothing new.

Hope this helps clear things up.


More information about the FreeTDS mailing list