[PD-dev] pix_multiblob mem leak

[Gerrie Roos]

>From the GemFAQ it appears that setting up a Windows build environment
is a pain...should I even attempt to set up my own?  What's the
chances of success within a couple of hours?

2010/3/15 Gerrie Roos <gerrieroos at gmail.com>:
> This is the first time looking at pd/gem code, so I might have it
> completely wrong, but the following looks suspicious:
>
> pix_multiblob.cpp:216:
>  t_atom*ap = new t_atom[2+blobNumber*8];
>
> ap then gets passed to outlet_anything and never freed.  I looked at
> some other examples of outlet_* usage and it always looks as if the
> memory passed is on the stack or freed again by the caller, e.g.:
> pix_record.cpp:184 is on the stack.  Is data always copied between
> outlet/inlets or am I missing some mechanism that optimizes by
> transferring pointer ownership?
>
> I couldn't find anything else in there that looks like it might leak.
>
>
> 2010/3/14 Gerrie Roos <gerrieroos at gmail.com>:
>> Hi, tnx for the reply!
>>
>> I started with Pd extented 0.41.4 (that's using Gem 0.91 I think) then
>> I installed a file marked as gem-0.92.2-W32-i686.exe (fresh from
>> http://gem.iem.at/) but if I look at the release notes in there it
>> looks like 0.91 as well, but the .dll is a different size, so I assume
>> the release notes are not up-to-date and I'm running 0.92.2.  Pd also
>> prints out 0.92.2 when it starts up.  Sorry, no beer yet...
>>
>> Clock.avi comes standard with Windows XP at least.  Here's a copy:
>> http://www.sendspace.com/file/smz01u
>>
>> Can't load alea.mpg with pix_film...just get an 'unable to open
>> file...error.  Weird.
>>
>> Tried homer.avi, also leaks 8(
>>
>> Originally found the problem using my usb webcam and played around
>> with the number of blobs quite a lot.  It always leaks when blobs are
>> detected.  Probably not the webcam since it leaks with clock.avi and
>> homer.avi as well.
>>
>>
>> 2010/3/14 IOhannes zmölnig <zmoelnig at iem.at>:
>>> Gerrie Roos wrote:
>>>> Hi!
>>>>
>>>> It looks like pix_multiblob is leaking about 4kB/frame/blob.  Anybody
>>>> else seen this?  I'm in a bit of a tight spot.  I've got an
>>>> installation coming up on 18 March and my extensive pd patch is now
>>>> running out of memory every couple of hours.  Would love to check out
>>>> the source code and try fix it myself but since I've never done any pd
>>>> dev it will put me back a couple of days (at the least).  I'll buy you
>>>> beer!
>>>>
>>>> Windows XP SP2
>>>> Pd version 0.41.4-extended
>>>
>>> what Gem version is this?
>>> does the problem exist with the latest and greatest Gem (0.92.2)? (if
>>> not, i claim the beer :-))
>>>
>>>
>>> thanks for sending an example patch; it's pretty generic, and i do not
>>> see any memleak occuring here (using the alea.mpg example film).
>>> however, the bug might be related to the number of blobs found and the
>>> image format, neither of which i can reproduce;
>>> could you put the clock.avi online somewhere so i can download it?
>>> or: how does your patch behave with homer.avi?
>>>
>>> fmadrs
>>> IOhannes
>>>
>>>
>>
>