|
Message-ID: <20030322165957.GA1979@openwall.com> 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.