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
Gerrie
Attached patch reproduces problem, reading video from file.
On Sat, Mar 13, 2010 at 10:07 AM, Gerrie Roos gerrieroos@gmail.com 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
Gerrie
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
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@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
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@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@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
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@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@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@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
On 2010-03-15 10:23, Gerrie Roos wrote:
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?
about 1% :-(
2010/3/15 Gerrie Roos gerrieroos@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];
indeed, this seems to be the trick. you can have your beer yourself.
i will try to do a bugfix release within the next few days (or at least send you an updated version)
fgmadsr IOhannes