FreeTDS Development Group

["Brian Bruns" <camber AT ais.org>]

Ok, 

It is a bug in the row buffering code.  You can replace buffer_clear() in 
src/dblib/dblib.c with the following one.  I'll check it into CVS tonight.

Cheers,

Brian

static void buffer_clear(DBPROC_ROWBUF *buf)
{
   buf->next_row         = 1;
   buf->first_in_buf     = 0;
   buf->newest           = -1;
   buf->oldest           = 0;
   buf->rows_in_buf      = 0;
   if (buf->rows) {
        free(buf->rows);
   }
   buf->rows             = NULL;

} /* buffer_clear()  */


On 11/09/99, ""Geoff Winkless" <geoff AT farmline.com>" wrote:
> Firstly, thanks everyone who's put any work into freetds, it's really
helped me out...

now my problem.

I started out with a large authentication routine which works flawlessly,
however I noticed that after a day running the program memory use had 
grown
to around 8MB.

I broke down the program...

If I create a simple routine which does:

  dbcmd(dbproc, "select top 1 fID from <<SOMETHING>>");
  dbsqlexec(dbproc);
  return_code = dbresults(dbproc);
  if (return_code == NO_MORE_RESULTS) {
    sprintf(mystr, "NORESULT\n");
    return -1;
  }

  while (return_code != NO_MORE_RESULTS) {
    if (return_code == SUCCEED) {
      while (dbnextrow(dbproc)  != NO_MORE_ROWS);
    }
    return_code = dbresults(dbproc);
  }
  return 0;
}                                     

and continuously call that function within a while(1==1) loop, calling 
with
a dbproc that I set up outside the function, I get a large memory leak 
problem -- the program starts at 840k and increases by 16kB every 1000 
results.

If I increase the number of columns I return the leak increases in speed 
as
you would expect.

Should I be "free"ing some objects in between calls to dbsqlexec()? Or is
there a bug somewhere?

I started out with 0.46 but have just tried the above code snippet on a 
different machine which I put .47 on and achieved the same results.

Thanks for any help/suggestions

Geoff