Skip to Content.
Sympa Menu

freetds - RE: re-use of dbprocess structure (was: Re: [freetds] stateofdbrpcsend())

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: re-use of dbprocess structure (was: Re: [freetds] stateofdbrpcsend())
  • Date: Fri, 9 Jul 2004 15:33:56 +0200

>
> 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);
> dbrpcparam();
> ...
> dbrpcsend();
> dbsqlok();
> while (dbresults() != NO_MORE_RESULTS) {
> /* dbbind points to stack variables only */
> dbbind();
> ....
> while (dbnextrow() != NO_MORE_ROWS) {
> /* process bound variables */
> }
> }
> if (dbhasretstat() == TRUE) {
> ret = dbrestatus(ctx->dbproc)
> /* do stuff here */
> }
> return;
> }
>
> 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.
>

Yes, this clear some things. Can you post entire code (with source store
procedure if you can) so I can try to reproduce it ?

freddy77




Archive powered by MHonArc 2.6.24.

Top of Page