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: "Coleman, Dave" <DColeman AT US.TIAuto.com>
  • To: 'TDS Development Group' <freetds AT franklin.oit.unc.edu>
  • Subject: Re: tds_process_login_tokens()
  • Date: Wed, 7 Aug 2002 08:10:30 -0400


If there had been a comment to that effect, this would have been a much
easier bug to trace. Adding comments would deal with this fine, I suppose.
Though I am curious myself why control of memory would be released to 3rd
party code in this way. That strikes me as somewhat dangerous, but since so
much is based on it being this way... I don't know... Like you said, open
the debate, sit back and watch the sparks fly.

Re: the non-persistant connection stuff... I have a working non-persistant
class (which *now* officially doesn't leak!) that I would be willing to
donate if such work would be appreciated. I don't know how compatible this
is with your goals as a project, but the first thing that I thought when I
started looking at freeTDS was "you mean I can't just open and close a
connection!?". Well, now I can, maybe other people would want to too... I
don't know what the protocol is on things like this, but as I've been
watching the messages regarding gethostbyname and the apparent elusiveness
of this other leak, I've realized that the functionality I have created for
myself here, would most likely be welcomed by many other freeTDS users. The
class leaks whatever gethostbyname() does on every delete, but that is the
only time it leaks. I ran the program overnight, it opened and closed a
connection to my SQL Server a couple hundred thousand times, ran a query
each time, returning an entire table, and it hasn't leaked a single bit.

cheers,
D

> -----Original Message-----
> From: Brian Bruns [SMTP:camber AT ais.org]
> Sent: Wednesday, August 07, 2002 7:35 AM
> To: TDS Development Group
> Subject: [freetds] Re: tds_process_login_tokens()
>
>
> If an API message handler is defined then it is responsible for reseting
> the message once it is done handling it. I think we should be a bit
> clearer
> in the function comments on this point. I'll check in a few snippits
> about it.
>
> Re: swaping the two lines. The reason the tds_free_msg() call is there
> is for the case that there is no handler defined libtds will clean up.
> Whether it should be doing that or not is open for debate I
> suppose, but swapping the two lines will presently require changes to
> dblib, ctlib, and odbc and all third party libtds apps. So, we should be
> very sure before breaking the API. It strikes me that there was a reason
> for doing it this way, but it escapes me at the moment.
>
> Brian
>
> On Wed, 7 Aug 2002, Coleman, Dave wrote:
>
> > feeling somewhat chagrined and also very curious to follow this to it's
> > conclusion, I have dug deeper than I have ever been into the freeTDS
> code.
> > Apparantly, commenting out the tds_process_login_tokens tree was
> preventing
> > tds_process_msg from being run, which was where the leak seemed to come
> > from. At least, the fix was rendered by calling tds_reset_msg_info from
> my
> > server message handling function. I have upgraded to yesterday's
> snapshot,
> > made the necessary modifications to deal with the addition of tds_ctx,
> and
> > also noticed the following in tds_process_msg: If a msg_handler is
> defined,
> > that handler must call tds_reset_msg_info or the program will leak.
> That
> > apparantly is the leak which disappears when I comment out
> > tds_process_login_tokens(). On much closer examination of the function,
> it
> > appears that if you swapped lines 1304 and 1305 of token.c, you might
> fix
> > the problem.
> >
> > [lines 1288-1306]
> > if(tds->msg_info->priv_msg_type
> > ? tds->tds_ctx->err_handler :
> > tds->tds_ctx->msg_handler) {
> > if (tds->msg_info->priv_msg_type)
> > tds->tds_ctx->err_handler(tds->tds_ctx, tds,
> > tds->msg_info);
> > else
> > tds->tds_ctx->msg_handler(tds->tds_ctx, tds,
> > tds->msg_info);
> > } else {
> > if(tds->msg_info->msg_number)
> > tdsdump_log(TDS_DBG_WARN,
> > "%L Msg %d, Level %d, State %d, Server %s, Line
> > %d\n%s\n",
> > tds->msg_info->msg_number,
> > tds->msg_info->msg_level,
> > tds->msg_info->msg_state,
> > tds->msg_info->server,
> > tds->msg_info->line_number,
> > tds->msg_info->message);
> > - tds_free_msg(tds->msg_info);
> > + }
> > - }
> > + tds_free_msg(tds->msg_info);
> > return rc;
> >
> > hope this helps
> >
> > D
> >
> > > -----Original Message-----
> > > From: ZIGLIO Frediano [SMTP:Frediano.Ziglio AT vodafoneomnitel.it]
> > > Sent: Wednesday, August 07, 2002 4:15 AM
> > > To: TDS Development Group
> > > Subject: [freetds] Re: tds_process_login_tokens()
> > >
> > > >
> > > > 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
> > > > ...
> > > >
> > >
> > > Perhaps glibc implement gethostbyname in a reentrant way. So it
> allocate a
> > > per-thread memory and return this memory to application. In thread
> exit if
> > > free memory (perhaps this is only a problem for main thread)
> > >
> > > Perhaps a program that call gethostbyname in a separate thread and
> join
> > > thread we should see the free..
> > >
> > >
> > > #include <stdio.h>
> > > #include <netdb.h>
> > > #include <sys/types.h>
> > > #include <netinet/in.h>
> > > #include <arpa/inet.h>
> > > #include <pthread.h>
> > > #ifdef DMALLOC
> > > #include <dmalloc.h>
> > > #endif
> > >
> > > void*
> > > test(void* arg)
> > > {
> > > struct hostent *host = NULL;
> > >
> > > host = gethostbyname("localhost");
> > >
> > > return NULL;
> > > }
> > >
> > > int
> > > main(int argc, char **argv)
> > > {
> > > pthread_t th;
> > > if (pthread_create(&th,NULL,test,NULL))
> > > return 1;
> > > pthread_join(th,NULL);
> > > return 0;
> > > }
> > >
> > > Results: it also allocate 8K for thread (and don't free it), removing
> > > gethostbyname allocate (and not free) only a chunk of 8K. But copying
> many
> > > time gethostbyname line do not waste other memory.
> > > Replicating also gethostbyname in main do waste other memory. So seem
> that
> > > glibc allocate some memory at the first call of gethostbyname.
> > >
> > > freddy77
> > >
> > > =================================
> > > "STRICTLY PERSONAL AND CONFIDENTIAL
> > >
> > > This message may contain confidential and proprietary material for the
> > > sole
> > > use of the intended recipient. Any review or distribution by others is
> > > strictly prohibited. If you are not the intended recipient please
> contact
> > > the sender and delete all copies.
> > > The contents of this message that do not relate to the official
> business
> > > of
> > > our company shall be understood as neither given nor endorsed by it."
> > >
> > > =================================
> > >
> > > ---
> > > You are currently subscribed to freetds as: [dColeman AT us.tiauto.com]
> > > To unsubscribe, forward this message to
> > > $subst('Email.Unsub')
> >
> > ---
> > You are currently subscribed to freetds as: [camber AT ais.org]
> > To unsubscribe, forward this message to
> $subst('Email.Unsub')
> >
> >
>
>
> ---
> You are currently subscribed to freetds as: [dColeman AT us.tiauto.com]
> To unsubscribe, forward this message to
> $subst('Email.Unsub')




Archive powered by MHonArc 2.6.24.

Top of Page