ev_loop_destroy memory leak

[Juan Pablo L]

thanks for replying, i have fixed the ev_unref issue and indeed was my
fault. i just did not understand what ev_TYPE_stop and ev_loop_destroy did
but i think i know now. the thread was trying to join while the loop was not
finished yet, i reference was held so now i stop the watcher, break the
loop, join the thread and destroy the loop, and it works (removed the
ev_unref call).

thanks!!!


On 28 December 2010 11:13, Marc Lehmann <schmorp at schmorp.de> wrote:

> On Tue, Dec 28, 2010 at 10:35:02AM -0400, Juan Pablo L <
> jpablolorenzetti at gmail.com> wrote:
> > Hi, i m trying to build an application using libev for the first time,
> this
> > application was written with glib but i m trying to change it into libev,
> i
> > have 1 issue and 1 question: the following code gives memory leaks at
> > ev_loop_destroy according to valgrind:
>
> Please check the libev documentation
> (http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#VALGRIND).
>
> In short, this is not a leak, it's simply a bug in valgrind.
>
> > ==13453== 0 bytes in 1 blocks are definitely lost in loss record 5 of 38
>
> Also, if you read the message in english: "no bytes were definitely
> lost...".
>
> > and also gives 9 errors (which are the 9 memory leaks) even thou it says
> 0
> > bytes was lost. so i have never seen this kind of reports before.
>
> If it bothers you you could report it against valgrind (pointing out to
> them that posix requires realloc (ptr, 0) to be the same as free, and that
> valgrind should either implement a posix-compliant mode or possibly point
> out that this is not a memory leak on any posix system (or even existing
> clones) with a better message).
>
> Valgrind not correctly implementing realloc and poll are known issues with
> it currently.
>
> > Also, i would like to know, why if i do not do an ev_unref after
> > statrting the watcher i get a segmentation fault when i stop the
> > application ? thanks!!!!
>
> I don't know, using threads is difficult and the program doesn't even
> link! Have you tried debugging it? It's very unlikely that it has anything
> to do with ev_unref or libev, except that it might actually let your
> program continue running.
>
> I would check if you access the loop in different threads without locking
> (except for ev_async_send). For example, are you sure you leave ev_run
> before calling ev_loop_destroy?
>
> --
>                The choice of a       Deliantra, the free code+content MORPG
>      -----==-     _GNU_              http://www.deliantra.net
>      ----==-- _       generation
>      ---==---(_)__  __ ____  __      Marc Lehmann
>      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
>      -=====/_/_//_/\_,_/ /_/\_\
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.schmorp.de/pipermail/libev/attachments/20101228/7bfd812d/attachment.html>