[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 22 Mar 2003 19:59:57 +0300
From: Solar Designer <solar@...nwall.com>
To: popa3d-users@...ts.openwall.com
Subject: Re: Possible memory leak?
On Sat, Mar 22, 2003 at 09:41:16AM +0500, Boris Kovalenko wrote:
> Solar Designer wrote:
> >On Fri, Mar 21, 2003 at 11:35:18AM +0500, Boris Kovalenko wrote:
> >>I wonder Due adopting I have found that we are allocating memory for
> >>virtual_spool in virtual.c/virtual_userpass function but can't find
> >>where we free the allocation. This is memory leak bug or I misunderstand
> >>something?
> >
> >This memory is really not freed anywhere, but the spool path may be
> >needed for almost the entire lifetime of the process from that point
> >on anyway. So this is not a bug, this is intentional.
> >
> Hmmm... What to not do it in pop_root.c?
And why do it?
Common sense first.
> For example with this type of code
>
> #if !POP_STANDALONE && !POP_OPTIONS
> int main(void)
> {
> int rc;
> if (do_pop_startup()) return 1;
> rc = do_pop_session();
> if(virtual_spool != NULL)
> free(virtual_spool);
> return rc;
> }
> #endif
You've added complexity for no gain. (And you've missed #if POP_VIRTUAL
so there would be even more added complexity.)
> Also, the same code we may use in standalone.c when fork'ed. Isn't?
Yes, do_pop_session() is also called from standalone.c. So what,
would you now also add complexity to standalone.c just to explicitly
free memory just before process exit?
And by complexity I mean more than added lines of code. It's also a
dependency on what values the virtual.c code assigns to virtual_spool.
That requirement would need to be documented and followed. Or the
free() call would need to be moved to a new virtual_done() function.
But there's really absolutely no need for all that!
--
/sd
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
