[Kdenlive-devel] Valgrind (Re: [PATCH kdenlive 00/27] cppcheck fixes)

[Pascal Fleury]

On Sun, Sep 18, 2011 at 8:51 AM, Mikko Rapeli <mikko.rapeli at iki.fi> wrote:

> On Sat, Sep 17, 2011 at 07:25:56PM -0700, Dan Dennedy wrote:
> > On Sat, Sep 17, 2011 at 1:49 PM, Mikko Rapeli <mikko.rapeli at iki.fi>
> wrote:
> > > On Sat, Sep 17, 2011 at 09:19:39PM +0200, Till Theato wrote:
> > >> -----BEGIN PGP SIGNED MESSAGE-----
> > >> Hash: SHA1
> > >>
> > >> On 08/28/2011 12:24 PM, Mikko Rapeli wrote:
> > >> > While waiting for proxy clips to be generated, I decided to run
> > >> > cppcheck on kdenlive and fix most of the issues found. I used
> > >> > cppcheck version
> > >>
> > >> Thanks a lot!
> > >> jbm applied all your patches in the meantime.
> > >
> > > You're welcome. I noticed them in git a few days back.
> > >
> > > Has anyone run valgrind with mlt and kdenlive?
> > >
> > > I noticed a ton of Qt related complains and a number of other items
> > > with leackcheck but most of the complains don't come from kdenlive
> directly.
> > > My first test case was just to start kdenlive without a project.
> >
> > I do occasionally with mlt. A number of things seem to occur with
> > dependencies and dlopen and related. For example, with swfdec, if it
> > is built against gstreamer, seems to generate a lot of complaints. I
> > made suppressions for things related to dlerror_run or things I
> > struggled to track down due to lack of symbols and that trace back to
> > mlt_factory_init (something that seems to occur once just due to
> > loading a plugin). However, coverage is another issue. I do not
> > usually have much time to create tests to exercise various code paths.
>
> Ok, I will try to run it while rendering one of my projects too.
>
> Btw, one of the findings which puzle me is this:
>
> ==9377== Invalid read of size 4
> ==9377==    at 0x4059AB4: mlt_properties_parse_yaml (mlt_properties.c:1611)
> ==9377==    by 0x20201F: ???
> ==9377==  Address 0xcaa34a8 is 48 bytes inside a block of size 51 alloc'd
> ==9377==    at 0x4023796: calloc (in
> /usr/lib/valgrind/vgpreload_memcheck-x86-li
> nux.so)
> ==9377==    by 0x4059A8B: mlt_properties_parse_yaml (mlt_properties.c:1609)
> ==9377==    by 0x20201F: ???
>
> Where code is:
>
> 1606                // Blank line (prepended with spaces) is new line
> 1607                if ( strcmp( name, "" ) == 0 )
> 1608                {
> 1609                        value = calloc( 1, strlen( old_value ) + 2 );
> 1610                        strcat( value, old_value );
> 1611                        strcat( value, "\n" );
> 1612                }
>
> To me this looks correct, but valgrind is constantly complaining about it.
>
>
Not so surprising if the implementation is this:
http://www.student.cs.uwaterloo.ca/~cs350/common/os161-src-html/strcat_8c-source.html
It uses pointer arithmetic, and hence copies stuff into a pointer that is
exactly 2 bytes less that you have calloc'd, that matches the length of the
input in your case. I thought that valgrind had a list of "known to work
fine issues it should not report" (= suppression lists), and the same should
apply for Qt.

You could create a suppression list for stuff you known you won't fix by
using the simple steps here:
http://wiki.wxwidgets.org/Valgrind_Suppression_File_Howto

--paf


> -Mikko
>
>
> ------------------------------------------------------------------------------
> BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
> http://p.sf.net/sfu/rim-devcon-copy2
> _______________________________________________
> Kdenlive-devel mailing list
> Kdenlive-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kdenlive-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdenlive/attachments/20110918/46deed4a/attachment.html>