On Sun, Sep 18, 2011 at 8:51 AM, Mikko Rapeli <mikko.rapeli@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@iki.fi> wrote:
> > On Sat, Sep 17, 2011 at 09:19:39PM +0200, Till Theato wrote:
> >> 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
==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:
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


BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
Kdenlive-devel mailing list