memory leak or something wrong
Marc Lehmann
schmorp at schmorp.de
Wed Jun 20 14:48:56 CEST 2012
On Wed, Jun 20, 2012 at 10:25:02AM +0800, yao liufeng <ylfroy at 163.com> wrote:
> > if size is equal to zero, and ptr is not NULL, then the call is
> > equivalent to free(ptr)
> >
> After doing some research, I think the issue is not about realloc(ptr, 0), it's about realloc(NULL, 0). According to C99 standard, malloc()
> If the size of the space requested is zero, the behavior is implementation-defined.
> If ptr is null, the realloc function behaves like the malloc function for the specified size.According to glibc, If n is zero, malloc returns a minumum-sized chunk. (The minimum
then debian broke compatibility with itself, because earleir manpages
document the traditional malloc(0)=0 behaviour of malloc.
debian should not have broken backwards compatibility when it can choose
between compatible implementation defined behaviour and incompatible
implementatioon defined behaviour, so this is a bug in debian in any case.
> And, just adding some trace to libev, we can find between ev_loop_new() and ev_loop_destroy(), several ev_realloc_emual(NULL, 0), by default realloc(NULL, 0) was triggered. This can explain where the memory leaks are from. And it's better for libev to deal with this situation.
As I said, yes, libev will work aorund this bug, but libev cannot deal
with this situation itself, because the problem is not in libev. If debian
chose to break all correct programs because they feel they need to change
malloc semantics then libev can't doa ynthing about this, as libev is
cetrainly not the only program that relied on documented behaviour here.
so libev can work around this in its own code, but not deal with this bug
in general.
--
The choice of a Deliantra, the free code+content MORPG
-----==- _GNU_ http://www.deliantra.net
----==-- _ generation
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ / schmorp at schmorp.de
-=====/_/_//_/\_,_/ /_/\_\
More information about the libev
mailing list