>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 <[email protected]>: > 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 <[email protected]>: >> 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 <[email protected]>: >>> 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 >>> >>> >> > _______________________________________________ Pd-dev mailing list [email protected] http://lists.puredata.info/listinfo/pd-dev
