After the release I demoed it some friends and obviously found some issues. Now I
spend the rest of the month tracking then. Its mostly ref-counts issues. Why are
the so nasty? Well unlike memory leaks, they are anonymous. Memory is allocated
once and should be paired by one free. The id of the resource is the memory
address. Now every ref should be paired by an unref, but all the refs and unrefs
share the same id (address of the object). So how to figure which ref is not
having the unref? Refdbg  can trace object and gather backtraces for
ref-count operations. So one has to go through the list one by one, remove pairs
and study whats left. Its not easy, but it works.
Now why is this so important. If the refcount never reaches 0, the object is not
disposed and occupies memory (until the application exits). Under valgrind it
would appear under reachable memory usually. For most apps it has no immediately
visible effect. For gstreamer app it has. In buzztard I do dynamic stuff with
pipelines, like adding and removing elements. If you get the ref-counting wrong.
The element is unlinked but not disposed. If the pipeline is set to PLAYING one
gets data flow errors. But then its not a gstreamer only problem. E.g. icon theme
pixbufs in gtk. If the are not unrefed, gtk cannot unload the theme. Means if
you try a bunch of themes, none of the is unloaded if even just one panel
applet has a ref-count issue. The sad thing is that the gnome libraries have
quite some ref-count leaks. I've started to track and fix them as its hard to
see something within all this noise .
I've released buzztard-0.3.1 with the fixes. A few more developments to mention:
Waffel started a demo for the zip loader based on libgsf, Deloun made great svg
designs for the machine view canvas and the tabs and Herzi send me a patch to
add native scrolling in the pattern editor. Now back to new features, yah!
buzztard core developer team
Log in to post a comment.