GNOME Bugzilla – Bug 746652
gst.supp improvements
Last modified: 2015-04-23 09:21:09 UTC
According to desrt, closures aren't very valgrind friendly because of pointer tricks. bug #739850 is supposed to improve the situation but for now adding a few entries to gst.supp allows me to have 0 leak reported with gst-validate.
Created attachment 300140 [details] [review] gst.supp: add some closure related entries According to desrt, closures aren't very valgrind friendly because of pointer tricks. bgo#739850 is supposed to improve the situation but for now adding a few entries to gst.supp allows me to have 0 leak reported with gst-validate. Fix
Actually let's use this bug for all the gst.supp improvevements I'm doing while valgrinding gst-validate tests.
Created attachment 300345 [details] [review] gst.supp: update gst-libav suppression - Fix the function wildcard: 'fun:*' doesn't work, '...' does - gst_ffmpegenc_register has been renamed to gst_ffmpegvidenc_register - Remove redundant suppressions, they are a subset of the most generic one
Created attachment 300351 [details] [review] gst.supp: add a suppression from libsoup Needed for tests using http.
Created attachment 300431 [details] [review] gst.supp: ignore leaks from libtool wrappers
Created attachment 300567 [details] [review] gst.supp: add a TLS/Pango related trace
Review of attachment 300431 [details] [review]: This one looks suspicious, why would the parser leak something ?
Review of attachment 300567 [details] [review]: This is a real leak isn't it ?
Review of attachment 300351 [details] [review]: Looks good.
Review of attachment 300345 [details] [review]: Looks good.
Review of attachment 300140 [details] [review]: Looks good.
Review of attachment 300431 [details] [review]: No idea, the wrapper is a shell script so I didn't bother digging more and just went for this easy workaround.
Review of attachment 300567 [details] [review]: Not clear, "possible" leaks are always tricky. I experienced similar false positives deep in the pango stack previously so didn't investigate much atm.
Review of attachment 300431 [details] [review]: Ok, this one will need work. This is a leak in a lex parser we have written (which in in C). The comment speaks about libtool and then you speak about a shell parser. This need to be checked.
Comment on attachment 300567 [details] [review] gst.supp: add a TLS/Pango related trace Does not apply anymore.
Comment on attachment 300345 [details] [review] gst.supp: update gst-libav suppression Someone equivalence has been merged.
Attachment 300140 [details] pushed as da5970f - gst.supp: add some closure related entries Attachment 300351 [details] pushed as 274c71f - gst.supp: add a suppression from libsoup
(In reply to Nicolas Dufresne (stormer) from comment #14) > Review of attachment 300431 [details] [review] [review]: > > Ok, this one will need work. This is a leak in a lex parser we have written > (which in in C). The comment speaks about libtool and then you speak about a > shell parser. This need to be checked. Which lex parser is that? This is how the leak is reported by valgrind so I assumed it was in libtool's shell wrapper. ==11031== 20,976 (32 direct, 20,944 indirect) bytes in 1 blocks are definitely lost in loss record 893 of 893 ==11031== at 0x4A08BCF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11031== by 0x47199A: xmalloc (in /usr/bin/bash) ==11031== by 0x43096B: make_if_command (in /usr/bin/bash) ==11031== by 0x42C060: yyparse (in /usr/bin/bash) ==11031== by 0x4229DA: parse_command (in /usr/bin/bash) ==11031== by 0x422AA7: read_command (in /usr/bin/bash) ==11031== by 0x422C88: reader_loop (in /usr/bin/bash) ==11031== by 0x4215CD: main (in /usr/bin/bash)
(In reply to Guillaume Desmottes from comment #6) > Created attachment 300567 [details] [review] [review] > gst.supp: add a TLS/Pango related trace For the record, this one can be reproduced using the "validate.file.compositor.simple.play_15s.synchronized" scenario.
(In reply to Guillaume Desmottes from comment #18) > (In reply to Nicolas Dufresne (stormer) from comment #14) > > Review of attachment 300431 [details] [review] [review] [review]: > > > > Ok, this one will need work. This is a leak in a lex parser we have written > > (which in in C). The comment speaks about libtool and then you speak about a > > shell parser. This need to be checked. > > Which lex parser is that? > > This is how the leak is reported by valgrind so I assumed it was in > libtool's shell wrapper. After some more investigations, I can confirm that this leak is indeed because of libtool's wrapper. It only occurs the first time we launch gst-validate-media-check-1.0 when tools/.libs/lt-gst-validate-media-check-1.0 hasn't been generated yet. I guess we hit some specific path in the shell script raising this leak.
Comment on attachment 300431 [details] [review] gst.supp: ignore leaks from libtool wrappers Good point, and with the entire stack trace it looks perfectly fine.
Comment on attachment 300431 [details] [review] gst.supp: ignore leaks from libtool wrappers Actually we don't need this any more. We are now using rpath when running from source in gst-validate so we don't have to bother about those wrappers.
So remains the pango supp, maybe we should merge it, it's not our fault, neither it's our code after all. Anyone has any opinion ?
(In reply to Nicolas Dufresne (stormer) from comment #23) > So remains the pango supp, maybe we should merge it, it's not our fault, > neither it's our code after all. Anyone has any opinion ? This one is actually fixed when using pixman master. Thibault and I decided to use a specific supp file for such known bugs (gstvalidate.supp). So I think we're all good for now; closing.