Skip to Content.
Sympa Menu

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

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] state ofdbrpcsend())
  • Date: Fri, 9 Jul 2004 12:54:11 +0200

>
> On Thu, Jul 08, 2004 at 11:50:58AM +0200, Frediano Ziglio wrote:
>
> > > Unless there are some objections (or offers) I'll start
> trying to patch
> > > the apparent numerous memory leaks in 0.62.4.
> > >
> >
> > This patch should fix the problem (committed in 0.63, not in 0.62)
>
> Thanks. I also sent a similar patch to James before you sent yours.
> Unfortunately, there is still a more subtle memory leak that I've
> been trying to track down.
>
> The test code leaks approximately 96-120 bytes per 1,000
> interations. I
> would expect that the leak variance between execution is due to page
> fragementation but I'll take other suggestions. However, it is still
> very puzzling as I would expect a consistent leak for every iteration
> not one page per 40 interations. Maybe a bad realloc() somewhere?
>

What do you mean by "96-120 bytes per 1000 iterations" ?
1000 iterations -> ~100 bytes
2000 iterations -> ~200 bytes
3000 iterations -> ~300 bytes
4000 iterations -> ~400 bytes
??
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).

> I've re-compiled FreeTDS with dmalloc, removed -O2 and added -g.
> The dmalloc report has libc functions like nss_* and dlopen_* on the
> not freed list which is probably okay. I did however see that
> strdup() and tsearch() were also on the list which is suspicious.
>
> I think dbcancel() needs to be modified to clear out the RPC
> structure and any paramaters so it can be called after use but I
> don't know if this is an appropriate course of action interms of
> other vendor impementations of dblib.
>
> I need to get rid of this memory leak, any other suggestions on what
> else it might be?
>
> Cheers.

I know there is a leak. filename used for dump it's not freed correctly.
I had also to patch dmalloc to add support for asprintf and vasprintf.

for strdup try a simple program like

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <dmalloc.h>

int main()
{
void *p = strdup("test strdup");
free(p);
return 0;
}

freddy77




Archive powered by MHonArc 2.6.24.

Top of Page