Skip to Content.
Sympa Menu

freetds - Re: tds_process_login_tokens()

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT ais.org>
  • To: TDS Development Group <freetds AT franklin.metalab.unc.edu>
  • Subject: Re: tds_process_login_tokens()
  • Date: Tue, 6 Aug 2002 23:26:12 -0400 (EDT)


On Mon, 5 Aug 2002, Coleman, Dave wrote:

> This leak occurs when the TDS API is used to log in and out multiple times.
> I was informed some time ago that this leak was none of your concern and was
> an artifact of gethostbyname(), which is obviously outside of your pervue.
> I hate to inform you that this is not the case. If tds_process_login_tokens
> is commented out of the login sequence, then the leak will not occur.
> (obviously, no connection will be made properly either, this is the
> problem). I am implementing this library for data collection on
> manufacturing equipment. This requires a non-persistant connection as a
> result of this environment. I have attatched a dump file. I have also
> added a few messages in your code, just for my own debugging, they were
> memory allocation type messages, and I swear that I have not modified any
> functional code.
>

Ok, I'll explain my methodology for testing memleaks in FreeTDS, hopefully
you'll do the same such that we can figure out where the disconnect is.

compiling and running the tsql.c application with dmalloc shows:

...
1028689292: 166: unknown memory: 54 pointers, 7163 bytes
...

in the log file.

I use this test program:

[camber@brian tds]$ cat foo.c
#include <stdio.h>
#include <netdb.h>
#include <sys/types.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#ifdef DMALLOC
#include <dmalloc.h>
#endif


int
main(int argc, char **argv)
{
struct hostent *host = NULL;

host = gethostbyname("localhost");

return 0;
}
[camber@brian tds]$

Which I compile in the following manner.

[camber@brian tds]$ gcc -c -o foo.o foo.c -I ~/src/dmalloc-4.8.2/ -DDMALLOC
[camber@brian tds]$ gcc -o foo foo.o -L ~/src/dmalloc-4.8.2/ -ldmalloc

and run, resulting in this log file:

...
1028689495: 62: unknown memory: 52 pointers, 3062 bytes
...

Obviously, FreeTDS is calling more functions than just gethostbyname() but
the relevant part is that a) FreeTDS has been compiled with dmalloc and
none of the memory addresses for unfree'd allocation are shown as coming
from the library itself, and b) this simple program demostrates at least
part of the leak is coming from allocations made by glibc on the
applications behalf (presumably scratch memory used by the non-reentrant
functions).

I caught a few memory leaks the first time through this exercise and those
were fixed. I'd be more than happy to discuss this further. If there are
flaws in my methodology, I'd be very keen to know what they are, but for
me commenting out tds_process_login_tokens does not affect the number of
bytes shown as unfree'd

Brian






Archive powered by MHonArc 2.6.24.

Top of Page