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: Wed, 7 Aug 2002 07:34:39 -0400 (EDT)



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')
>
>





Archive powered by MHonArc 2.6.24.

Top of Page