Thread: Re: [PATCHES] Re: [HACKERS] Everything leaks; How it mm suppose to work?
Re: [PATCHES] Re: [HACKERS] Everything leaks; How it mm suppose to work?
From
"Vadim B. Mikheev"
Date:
Bruce Momjian wrote: > > > I seem to recall a discussion a long time ago about using strdup and how > > it would leak when using the postgres memory contexts, and that the pstrdup > > code was created to be used instead of strdup to "fix" this. > > > > OK, here is a patch to fix the memory leak problem. Not sure when this > was introduced, but who cares. Probably not Vadim, as I first thought. (Sure - not me :). Congratulations with finding this! storage/buffer/bufmgr.c:BufferAlloc(): strcpy(buf->sb_dbname, GetDatabaseName()); and so we had leak for _every_ new buffer allocation! But why strdup() was added there? (Hope that nothing is broken now). Vadim
> > Bruce Momjian wrote: > > > > > I seem to recall a discussion a long time ago about using strdup and how > > > it would leak when using the postgres memory contexts, and that the pstrdup > > > code was created to be used instead of strdup to "fix" this. > > > > > > > OK, here is a patch to fix the memory leak problem. Not sure when this > > was introduced, but who cares. Probably not Vadim, as I first thought. > > (Sure - not me :). Congratulations with finding this! > storage/buffer/bufmgr.c:BufferAlloc(): > > strcpy(buf->sb_dbname, GetDatabaseName()); > > and so we had leak for _every_ new buffer allocation! > > But why strdup() was added there? (Hope that nothing is broken now). No idea, but it was not needed. Removed the strdup, changed the function to return a const char, and everything worked, so nothing was changing the value. (pstrdup() did not work because the allocation was probably being done in the CacheCxt). Also checked each call, and no one was changing the variable, so no need for the strdup(). In fact, I am going to remove the Get/Set functions entirely(too many calls), make it a global variable, and add to the TODO list: for safety, make global variables const, cast to non-const as needed This will be a more general solution for global variable protection. -- Bruce Momjian | 830 Blythe Avenue maillist@candle.pha.pa.us | Drexel Hill, Pennsylvania 19026 + If your life is a hard drive, | (610) 353-9879(w) + Christ can be your backup. | (610) 853-3000(h)