LV: leaking memory about libvisual HOT 10 CLOSED

Was this report produced with --leak-check=full? If it was, then the leaks are not limited to plazma.

from libvisual.

Chong Kai Xiong [email protected] schrieb:

Was this report produced with with --leak-check=full? If it was, then
the leaks are not limited to plazma.

---

Reply to this email directly or view it on GitHub:
#5 (comment)

yes it was, but they weren't caused by other actors iirc. can do another check later.

from libvisual.

you are right, here is the output for lv_analyzer with stdout driver (to remove SDL leaks):

https://gist.github.com/4556737

from libvisual.

I've closed all the VisParam-related leaks on plugin unloads with 1563c00

Apart from some plugins not properly freeing their private data pointers after encountering errors during init(), I am confident that there are no serious system-wide leaks left. valgrind --leak-check=full doesn't show anything except leaks within SDL. I believe we can close this issue. Any leaks with individual plugins can be filed separately.

from libvisual.

still getting some leaks: https://gist.github.com/4708164

from libvisual.

Alright I should've completely fixed the VisPluginData leaks. The ones remaining I can catch are from calls to ORC routines, SDL/Xlib and dlfcn: https://gist.github.com/4708432

from libvisual.

I still get various leaks, related to RandomContext, DFT, System, PluginRegistry etc: https://gist.github.com/4712770
If exactly the same command is used (first line of paste), outputs are comparable (use stdout driver to eliminate X/SDL leaks). Though this only covers lv_analyzer, it's a good starting point.

from libvisual.

Try limiting the number of frames with -F for the program to terminate normally. It reveals no leaks for me. Breaking out from lv-tool with Ctrl-C will not call the C++ destructors.

from libvisual.

indeed that reduces leaked memory significantly, still there are leaks left: https://gist.github.com/4712879
I'm not sure whether lv-tool should have a signal handler to exit cleanly on ctrl+c ... should it?

from libvisual.

Sure why not? It's quite simple to add on POSIX systems (still looking for a Windows example):
http://stackoverflow.com/questions/4250013/is-destructor-called-if-sigint-or-sigstp-issued

Edit: C has a portable way to handle process signals (signal.h)

I don't really consider the reported leaks in SDL, Xlib or ORC problems we can fix, so they shouldn't be under the scope of this issue.

from libvisual.