GNOME Bugzilla – Bug 775456
memory leaks during build process
Last modified: 2017-04-19 12:50:33 UTC
If I build gstreamer with clang and address sanitizer it will report memory leaks during the build process. To reproduce: * Clone the gstreamer repo and run autogen.sh * ./configure --disable-gtk-doc --enable-debug CC=clang CFLAGS="-fsanitize=address -g -O2"; make I'm not exactly sure which code is causing that leak, but it seems to be some temporary created executable related to introspection. Here's the relevant output of ASAN_OPTIONS="fast_unwind_on_malloc=0" make V=1 : GST_PLUGIN_SYSTEM_PATH_1_0="" GST_PLUGIN_PATH_1_0="" GST_REGISTRY_UPDATE=no GI_SCANNER_DISABLE_CACHE=yes \ CPPFLAGS="" CFLAGS="-fsanitize=address -g -O2" LDFLAGS="" CC="clang" PKG_CONFIG="/usr/bin/pkg-config" DLLTOOL="false" \ /usr/bin/g-ir-scanner -v --namespace Gst \ --nsversion=1.0 \ --verbose \ --warn-all \ -I.. \ -I.. \ -DIN_GOBJECT_INTROSPECTION=1 \ --c-include='gst/gst.h' \ --library=libgstreamer-1.0.la \ --include=GLib-2.0 \ --include=GObject-2.0 \ --include=GModule-2.0 \ --libtool="/bin/sh ../libtool" \ --pkg glib-2.0 \ --pkg gobject-2.0 \ --pkg gmodule-no-export-2.0 \ --pkg-export gstreamer-1.0 \ --add-init-section="extern void gst_init(gint*,gchar**); gst_init(NULL,NULL);" \ --output Gst-1.0.gir \ ./gst.h ./glib-compat.h ./gstobject.h ./gstallocator.h ./gstbin.h ./gstbuffer.h ./gstbufferlist.h ./gstbufferpool.h ./gstbus.h ./gstcaps.h ./gstcapsfeatures.h ./gstchildproxy.h ./gstclock.h ./gstcompat.h ./gstcontext.h ./gstcontrolbinding.h ./gstcontrolsource.h ./gstdatetime.h ./gstdebugutils.h ./gstelement.h ./gstelementmetadata.h ./gstdevice.h ./gstdeviceprovider.h ./gstdeviceproviderfactory.h ./gstdynamictypefactory.h ./gstelementfactory.h ./gsterror.h ./gstevent.h ./gstformat.h ./gstghostpad.h ./gstdevicemonitor.h ./gstinfo.h ./gstiterator.h ./gstatomicqueue.h ./gstmacros.h ./gstmessage.h ./gstmeta.h ./gstmemory.h ./gstminiobject.h ./gstpad.h ./gstpadtemplate.h ./gstparamspecs.h ./gstpipeline.h ./gstplugin.h ./gstpluginfeature.h ./gstpoll.h ./gstpreset.h ./gstprotection.h ./gstquery.h ./gstsample.h ./gstsegment.h ./gststreamcollection.h ./gststreams.h ./gststructure.h ./gstsystemclock.h ./gsttaglist.h ./gsttagsetter.h ./gsttask.h ./gsttaskpool.h ./gsttoc.h ./gsttocsetter.h ./gsttracer.h ./gsttracerfactory.h ./gsttracerrecord.h ./gsttypefind.h ./gsttypefindfactory.h ./gsturi.h ./gstutils.h ./gstvalue.h ./gstregistry.h ./gstparse.h ./math-compat.h ./gstenumtypes.h ./gstversion.h \ ./gst.c ./gstobject.c ./gstallocator.c ./gstbin.c ./gstbuffer.c ./gstbufferlist.c ./gstbufferpool.c ./gstbus.c ./gstcaps.c ./gstcapsfeatures.c ./gstchildproxy.c ./gstclock.c ./gstcontext.c ./gstcontrolbinding.c ./gstcontrolsource.c ./gstdatetime.c ./gstdebugutils.c ./gstdevice.c ./gstdevicemonitor.c ./gstdeviceprovider.c ./gstdeviceproviderfactory.c ./gstdynamictypefactory.c ./gstelement.c ./gstelementfactory.c ./gsterror.c ./gstevent.c ./gstformat.c ./gstghostpad.c ./gstinfo.c ./gstiterator.c ./gstatomicqueue.c ./gstmessage.c ./gstmeta.c ./gstmemory.c ./gstminiobject.c ./gstpad.c ./gstpadtemplate.c ./gstparamspecs.c ./gstpipeline.c ./gstplugin.c ./gstpluginfeature.c ./gstpluginloader.c ./gstpoll.c ./gstpreset.c ./gstprotection.c ./gstquark.c ./gstquery.c ./gstregistry.c ./gstregistrychunks.c ./gstsample.c ./gstsegment.c ./gststreamcollection.c ./gststreams.c ./gststructure.c ./gstsystemclock.c ./gsttaglist.c ./gsttagsetter.c ./gsttask.c ./gsttaskpool.c ./gsttoc.c ./gsttocsetter.c ./gsttracer.c ./gsttracerfactory.c ./gsttracerrecord.c ./gsttracerutils.c ./gsttypefind.c ./gsttypefindfactory.c ./gsturi.c ./gstutils.c ./gstvalue.c ./gstparse.c ./gstregistrybinary.c ./gstenumtypes.c g-ir-scanner: link: /bin/sh ../libtool --mode=link --tag=CC clang -o /mnt/ram/gstreamer/gst/tmp-introspectzUywhI/Gst-1.0 -export-dynamic -fsanitize=address -g -O2 tmp-introspectzUywhI/mnt/ram/gstreamer/gst/tmp-introspectzUywhI/Gst-1.0.o -L. libgstreamer-1.0.la -lgio-2.0 -Wl,--export-dynamic -lgmodule-2.0 -pthread -lgobject-2.0 -lgmodule-2.0 -pthread -lglib-2.0 libtool: link: clang -o /mnt/ram/gstreamer/gst/tmp-introspectzUywhI/.libs/Gst-1.0 -fsanitize=address -g -O2 tmp-introspectzUywhI/mnt/ram/gstreamer/gst/tmp-introspectzUywhI/Gst-1.0.o -Wl,--export-dynamic -pthread -pthread -Wl,--export-dynamic -L. ./.libs/libgstreamer-1.0.so -lunwind -ldw -lelf -lm -lrt -ldl -lgio-2.0 -lgobject-2.0 -lgmodule-2.0 -lglib-2.0 -pthread ================================================================= ==32237==ERROR: LeakSanitizer: detected memory leaks Direct leak of 16384 byte(s) in 1 object(s) allocated from: #0 0x4cd508 in malloc (/mnt/ram/gstreamer/gst/tmp-introspectzUywhI/.libs/Gst-1.0+0x4cd508) #1 0x7fa78142a4c8 in g_malloc (/usr/lib64/libglib-2.0.so.0+0x4e4c8) #2 0x7fa7814351bb (/usr/lib64/libglib-2.0.so.0+0x591bb) #3 0x7fa783002369 in call_init /var/tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/elf/dl-init.c:72 #4 0x7fa78300247a in call_init /var/tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/elf/dl-init.c:30 #5 0x7fa78300247a in _dl_init /var/tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/elf/dl-init.c:120 #6 0x7fa782ff3c49 (/lib64/ld-linux-x86-64.so.2+0xc49) SUMMARY: AddressSanitizer: 16384 byte(s) leaked in 1 allocation(s). Command '[u'/mnt/ram/gstreamer/gst/tmp-introspectzUywhI/Gst-1.0', u'--introspect-dump=/mnt/ram/gstreamer/gst/tmp-introspectzUywhI/functions.txt,/mnt/ram/gstreamer/gst/tmp-introspectzUywhI/dump.xml']' returned non-zero exit status 1
This looks like a leak in GLib. It might be an intentional leak, but it's hard to know without glib debug info. Does LeakSanitizer have a suppression file/list like valgrind? (It's going to be needed)
If it helps here with glib debugging enabled: Direct leak of 16384 byte(s) in 1 object(s) allocated from: #0 0x4cd508 in malloc (/mnt/ram/gstreamer/gst/tmp-introspectlnO_JK/.libs/Gst-1.0+0x4cd508) #1 0x7f181f83b4a8 in g_malloc /var/tmp/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/glib/gmem.c:94 #2 0x7f181f84619b in g_quark_init /var/tmp/portage/dev-libs/glib-2.50.2/work/glib-2.50.2/glib/gquark.c:62 #3 0x7f1821413369 in call_init /var/tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/elf/dl-init.c:72 #4 0x7f182141347a in call_init /var/tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/elf/dl-init.c:30 #5 0x7f182141347a in _dl_init /var/tmp/portage/sys-libs/glibc-2.23-r3/work/glibc-2.23/elf/dl-init.c:120 #6 0x7f1821404c49 (/lib64/ld-linux-x86-64.so.2+0xc49)
That looks like the global quark table. It's probably intentional. Not much we can do about that I think. I can re-assign to GLib but I suspect it's WONTFIX :)
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!