Pd-dev April 2009

pd-dev@lists.iem.at

13 participants
143 discussions

trying to compile PD-extended on 64bit ubuntu
by Kasper Jordaens 28 Apr '09

28 Apr '09

Hi all, I've been trying to compile 64bit PD-extended on my unbuntu hardy machine. 32bit PD is not an option as it segfaults on trying to connect to jackd. I largely succeeded allready, meaning many externals compile fine. I check the list archives for pointers, and got stuck on other places. Here is what I've done so far: get source install deps listed here http://puredata.info/docs/developer/Debian sudo apt-get install ia32-libs lib32z1-dev lib32bz2-dev (for the "stub-32h error") cd /packages/linux_make make install && make package notice Gem is missing wget http://puredata.info/community/projects/software/gem/releases/0.91.3/gem-0.… untar mv gem-0.91-3 Pd-0.40.3-extended/Gem compile again notice lamelibs are missing apt-get install libmp3lame0 libmp3lame-dev after that I get these errors.... dunno how to deal with those... 12.5-darcs\" -I. -I/usr/X11R6/include -I../include -I../../include -I/home/kaos/Pd-0.40.3-extended/pd/src -o pdp_convert.o -c pdp_convert.c gcc -DPD -Wall -W -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch -fPIC -O2 -funroll-loops -fomit-frame-pointer -ffast-math -DPDP_VERSION=\"0.12.5-darcs\" -I. -I/usr/X11R6/include -I../include -I../../include -I/home/kaos/Pd-0.40.3-extended/pd/src -o pdp_udp_send.o -c pdp_udp_send.c gcc -DPD -Wall -W -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch -fPIC -O2 -funroll-loops -fomit-frame-pointer -ffast-math -DPDP_VERSION=\"0.12.5-darcs\" -I. -I/usr/X11R6/include -I../include -I../../include -I/home/kaos/Pd-0.40.3-extended/pd/src -o pdp_udp_receive.o -c pdp_udp_receive.c gcc -DPD -Wall -W -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch -fPIC -O2 -funroll-loops -fomit-frame-pointer -ffast-math -DPDP_VERSION=\"0.12.5-darcs\" -I. -I/usr/X11R6/include -I../include -I../../include -I/home/kaos/Pd-0.40.3-extended/pd/src -o pdp_rawin.o -c pdp_rawin.c gcc -DPD -Wall -W -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch -fPIC -O2 -funroll-loops -fomit-frame-pointer -ffast-math -DPDP_VERSION=\"0.12.5-darcs\" -I. -I/usr/X11R6/include -I../include -I../../include -I/home/kaos/Pd-0.40.3-extended/pd/src -o pdp_rawout.o -c pdp_rawout.c pdp_rawout.c: In function Ã¢rawout_dspÃ¢: pdp_rawout.c:245: warning: cast from pointer to integer of different size In function Ã¢openÃ¢, inlined from Ã¢rawout_threadÃ¢ at pdp_rawout.c:141: /usr/include/bits/fcntl2.h:51: error: call to Ã¢__open_missing_modeÃ¢ declared with attribute error: open with O_CREAT in second argument needs 3 arguments make[5]: *** [pdp_rawout.o] Error 1 make[5]: Leaving directory `/home/kaos/Pd-0.40.3-extended/externals/pdp/modules/generic' make[4]: *** [current] Error 2 make[4]: Leaving directory `/home/kaos/Pd-0.40.3-extended/externals/pdp/modules' Ideas? I looked up all referenced sourcecode: pdp_rawout.c:245: warning: cast from pointer to integer of different size args[0] = (int)x; pdp_rawout.c:141: if (-1 == (pipefd = open(x->x_pipe->s_name, O_WRONLY|O_CREAT))){ perror(me); goto exit; } /usr/include/bits/fcntl2.h:51: if ((__oflag & O_CREAT) != 0 && __va_arg_pack_len () < 1) { __open_missing_mode (); return __open_2 (__path, __oflag); } Thanks Kasper

2 1

open_via_path() weirdness
by IOhannes m zmoelnig 28 Apr '09

28 Apr '09

hi all, in the course of trying to find the filehandle-leak bug in Gem i found a weird problem with open_via_path(). can anybody find anything wrong with the attached code? if not, try the attached patch as well. everything works fine on linux, but on w32 i cannot close the file-handle anymore (i get an errno of EBADF, which means that fd isn't a valid open file descriptor). which in turn results in a filehandle leak. i notice that hardly anyone (esp. Pd itself) uses open_via_path(). is there a reason for that? is it buggy? (couldn't find anything wrong though) i use it quite a lot, e.g. in [msgfile]; i guess nobody ever tried to open > 1000 files with msgfile on w32, so the error never appeared... fgamsdr IOhannes #N canvas 355 251 450 300 10; #X obj 165 160 findfile; #X obj 165 113 until; #X msg 165 132 symbol findfile-test.pd; #X msg 165 90 100; #X connect 1 0 2 0; #X connect 2 0 0 0; #X connect 3 0 1 0;

3 4

[ pure-data-Bugs-2130873 ] gem fullscreen
by SourceForge.net 28 Apr '09

28 Apr '09

Bugs item #2130873, was opened at 2008-09-26 19:59 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2130873&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pd-extended Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: megalegoland (megalegoland) Assigned to: Hans-Christoph Steiner (eighthave) Summary: gem fullscreen Initial Comment: when using [fullscreen 1(--[gemwin] error: GEM: no xxf86vm-support: cannot switch to fullscreen ubuntu 8.04 i386 ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2009-04-28 02:26 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2009-04-13 23:15 Message: libxxf86vm-dev is installed on most of the GNU/Linux build machines for a while now, and I just installed it on the Debian/testing, Debian/etch/PowerPC, Debian/etch/i386, Ubuntu/Hardy/LPIA and Ubuntu/Jaunty machines. Please try a nightly build and check if this is working: http://autobuild.puredata.info/auto-build/latest/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2130873&group_…

1 0

[ pure-data-Bugs-2630421 ] [model foobar.obj] crashes when no gemwin is created before.
by SourceForge.net 28 Apr '09

28 Apr '09

Bugs item #2630421, was opened at 2009-02-23 15:15 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2630421&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pd-extended Group: None >Status: Closed Resolution: None Priority: 5 Private: No Submitted By: crinimal (crinimal) Assigned to: Nobody/Anonymous (nobody) Summary: [model foobar.obj] crashes when no gemwin is created before. Initial Comment: Hi, when using [model foo.obj] and no gemwin has been created before, pd exits with segfault. this also happens on message [open foo.obj( everything's fine when I create a gemwin, even if i destroy it and then load a patch containing [model foo.obj] I'm using pd 0.40.3-extended from otherside.servebeer.com intrepid repository. thanks, Martin below output of pd: tk scaling is 1.33483483483 GEM: Graphics Environment for Multimedia GEM: ver: 0.91.0 'tigital' GEM: compiled: Dec 3 2008 GEM: maintained by IOhannes m zmoelnig GEM: Authors : Mark Danks (original version) GEM: Chris Clepper GEM: James Tittle GEM: IOhannes m zmoelnig GEM: with help by Guenter Geiger, Daniel Heckenberg, Cyrille Henry, et al. GEM: found a bug? miss a feature? please report it: GEM: homepage http://gem.iem.at/ GEM: bug-tracker http://sourceforge.net/projects/pd-gem/ GEM: mailing-list http://lists.puredata.info/listinfo/gem-dev/ GEM: compiled for SIMD architecture: MMX GEM: using MMX optimization PDP: pure data packet version 0.12.5-darcs PiDiP : additional video processing objects for PDP version 0.12.22 ( ydegoyon(a)free.fr ) pdp_colorgrid: version 0.4 by Yves Degoyon (ydegoyon(a)free.fr) & Lluis Gomez i Bigorda (lluis(a)artefacte.org) _glmFindMaterial(): can't find material "(null)". pd_gui: pd process exited zsh: segmentation fault pd -stderr robot-arms.pd ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2009-04-28 02:26 Message: This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-04-15 05:57 Message: i created a thread for this some time ago in the mailing list: http://lists.puredata.info/pipermail/pd-list/2009-03/068425.html apparently the cause of these errors seems to be radeon graphics driver or graphics hardware. the work around: [create( [gemwin] before loading any models is still necessary on this computer with current versions of extended autobuilds. on another computer (nvidia graphics) everything's fine. tested today 2009_04_15 on Pd version 0.41-4extended-20090323 compiled 11:51:58 Mar 23 2009 ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2009-04-13 21:28 Message: I couldn't reproduce this on Mac OS X 10.5/Intel Pd version 0.41.4-extended-20090413. I am guessing it might have something to do with that "otherside" build, which is not from the standard build servers. Try one of the nightly intrepid builds: http://autobuild.puredata.info/auto-build/latest/ ---------------------------------------------------------------------- Comment By: Cyrille Henry (nusmuk) Date: 2009-02-23 17:49 Message: This can not be reproduce on Gem cvs / intrepid. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2630421&group_…

1 0

[ pure-data-Patches-1936157 ] make "list" messages be real float/symbol/bang messages
by SourceForge.net 25 Apr '09

25 Apr '09

Patches item #1936157, was opened at 2008-04-06 14:17 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1936157&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: feature Status: Open Resolution: None Priority: 5 Private: No Submitted By: IOhannes m zmlnig (zmoelnig) >Assigned to: Hans-Christoph Steiner (eighthave) Summary: make "list" messages be real float/symbol/bang messages Initial Comment: in the past there has been some attempts to make "list" messages behave like "float" (or "symbol" or "bang") messages and vice-versa. the attached patch adds some additional fallbacks to the method dispatcher in inlet_list(): if an object has no real list-method for an inlet but a float-method and it receives a one-element list holding a float, it will call the float-method. the same for symbols. if there is no list-method and the object receives an empty "list" message, it will call the objects "bang_method" this should fix bugs #1890931 and #1749885. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2009-04-25 16:26 Message: I am going to assign this to me for now so that I remember to included it in the Pd-extended 0.42 branch, unless anyone has any objections. Then I'll assign it to Miller... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1936157&group_…

1 0

[ pure-data-Bugs-1733623 ] audio math objects don't handle one-element lists as floats
by SourceForge.net 25 Apr '09

25 Apr '09

Bugs item #1733623, was opened at 2007-06-08 11:36 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1733623&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: puredata >Group: v0.42 Status: Open Resolution: Fixed Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) >Assigned to: Miller Puckette (millerpuckette) Summary: audio math objects don't handle one-element lists as floats Initial Comment: If you send a one-float-element list, such as [list 123(, into the right inlet of a [*~], [+~], [-~], etc., you get the following error message: "error: inlet: expected 'signal' but got 'list'" Instead, the one-element list should be treated just as a float, since: 1) [*~], [+~] etc. accept floats on its right inlet 2) a one-float-element list is supposed to be equivalent to a float to all effects in PD. All control objects (including [route] and math operators) handle one-float-element lists as floats, and one-symbol-element lists as symbols. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2009-04-25 16:19 Message: Confirmed on Mac OS X 10.5.6/Intel using Pd version 0.41.4-extended-20090422 and Pd-vanilla 0.42-4. ---------------------------------------------------------------------- Comment By: IOhannes m zmlnig (zmoelnig) Date: 2008-04-07 05:25 Message: Logged In: YES user_id=564396 Originator: NO i posted a fix as patch-#1936157 https://sourceforge.net/tracker/index.php?func=detail&aid=1936157&group_id=… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1733623&group_…

1 0

Re: [PD-dev] win32 build farm 'msys.exe' (WAS: symlinks render pdstring unbuildable on MinGW/Windows)
by Bryan Jurish 25 Apr '09

25 Apr '09

moin Hans, moin list, On 2009-04-20 02:10:17, Hans-Christoph Steiner <hans(a)eds.org> appears to have written: > On Apr 19, 2009, at 5:22 AM, Bryan Jurish wrote: >> moin Hans, >> On 2009-04-18 06:57:53, Hans-Christoph Steiner <hans(a)eds.org> appears to >> have written: >>> >>> The bad news is that it seems that my bad diagnosis led you on a wide >>> goose chase thru the pain of Windows development. >> >> It may or may not have been a bad diagnosis (although it certainly was a >> pain ;-) -- I still haven't verified the former, since I don't use (or >> understand) all of the auto-build scripts. I'm still kinda hoping >> IOhannes might make some headway there... > > You don't really need to understand the auto-build scripts, all that > needs to work is this: > > cd pure-data/externals > make moocow > make moocow_install yup, I've understood that bit (and the motivations, I think). I meant that since the problems arising in 'make moocow' appear to have been *due to* clever & fiendish details of earlier scripts (e.g. use of rsync rather than svn, the cygwin/mingw dichotomy, etc. etc.), it would have behooved me to have understood those scripts better (e.g. at all)... >>> Apparently, >>> string2any and friends are still not getting built. In fact all of the >>> 'moocow' is empty on Windows. This is still stumping me. The win32 build farm machine's config.log is showing me (for externals/moocow/locale): configure:2701: gcc \ -DPD -O2 -mcpu=i586 -mtune=pentium3 \ -I/home/pd/auto-build/pd-extended/pd/src \ -Wall -W -ggdb \ -I/home/pd/auto-build/pd-extended/Gem/src \ -mms-bitfields \ -DMSW -DNT -D'O_NONBLOCK=1' -D'srand48(n)=srand((n))' \ -D'drand48()=((double)rand()/RAND_MAX)' -D'bzero(p,n)=memset(p,0,n)' \ -L/home/pd/auto-build/pd-extended/pd/bin \ conftest.c >&5 <command line>:4:1: macro names must be identifiers <command line>:5:1: macro names must be identifiers <command line>:6:1: macro names must be identifiers <command line>:7:1: macro names must be identifiers configure:2704: $? = 1 configure:2742: result: configure: failed program was: | /* confdefs.h. */ | #define PACKAGE_NAME "locale" | #define PACKAGE_TARNAME "locale" | #define PACKAGE_VERSION "0.02-1" | #define PACKAGE_STRING "locale 0.02-1" | #define PACKAGE_BUGREPORT "moocow(a)ling.uni-potsdam.de" | #define PACKAGE "locale" | #define VERSION "0.02-1" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:2749: error: C compiler cannot create executables ... newline escapes in the gcc call added post-hoc for legibility. The above call works fine (creating a.exe) by hand on the build farm win32 machine with "/cygdrive/c/msys/1.0/bin:/cygdrive/c/MinGW/bin" prepended to PATH, so I can't grok where things might be going wrong, much less what the "macro names must be identifiers" errors are all about -- assumedly some of the '-D' flags are giving me grief, but since I can't reproduce the error, I can't tell which ones or what to do about it. Anyone have any ideas? I can't use rdesktop currently, since it's telling me I'd have to kick out another user (pd). >> In a related question, should the auto-build process for the win32 >> build-farm machine be trying to build everything from the LIB_TARGETS >> variable in externals/Makefile? If so, then I must be being pretty >> dense, because I can't see where my builds are getting called (I see >> install calls, but no configuration or compilation), much less where >> they might be failing... > > You are correct. Search for 'moocow_install:' in externals/Makefile. > That's where its being called. Yes, right; but I couldn't see (until the rsync fix/hack was applied) where the 'moocow' target was getting called, thus recursing into externals/moocow/extended. That's showing up now, so no worries. marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." jurish(a)ling.uni-potsdam.de -Lubarsky's Law of Cybernetic Entomology

2 2

proper debs (pure:dyne+pd-extended = good)
by Hans-Christoph Steiner 25 Apr '09

25 Apr '09

Hey, I don't know if any of the active pure:dyne packagers are on this list, but I thought I'd try. From what I have seen, it looks like pure:dyne is doing a much better job of making .deb packages than Pd- extended. I would be great to 'officially' merge efforts so that we don't duplicate work. Then we can make some really nice, proper packages and get them into Debian. DebConf 2010 is in NYC, and I'll be helping to run it, so it would be great to have all this in Debian by then. Plus, it seems that Guenter has less time for the Debian packages, so things like the pd-externals package has lapsed. It seems to me that the next step would be to get the pure:dyne stuff into pure-data SVN, then make any tweaks to it to make it work with Pd- extended too. .hc ---------------------------------------------------------------------------- Mistrust authority - promote decentralization. - the hacker ethic

2 4

Re: [PD-dev] win32 build farm 'msys.exe' (WAS: symlinks render pdstring unbuildable on MinGW/Windows)
by Hans-Christoph Steiner 25 Apr '09

25 Apr '09

On Apr 24, 2009, at 3:20 PM, Bryan Jurish wrote: > moin Hans, moin list, > > On 2009-04-20 02:10:17, Hans-Christoph Steiner <hans(a)eds.org> > appears to > have written: >> On Apr 19, 2009, at 5:22 AM, Bryan Jurish wrote: >>> moin Hans, >>> On 2009-04-18 06:57:53, Hans-Christoph Steiner <hans(a)eds.org> >>> appears to >>> have written: >>>> >>>> The bad news is that it seems that my bad diagnosis led you on a >>>> wide >>>> goose chase thru the pain of Windows development. >>> >>> It may or may not have been a bad diagnosis (although it certainly >>> was a >>> pain ;-) -- I still haven't verified the former, since I don't use >>> (or >>> understand) all of the auto-build scripts. I'm still kinda hoping >>> IOhannes might make some headway there... >> >> You don't really need to understand the auto-build scripts, all that >> needs to work is this: >> >> cd pure-data/externals >> make moocow >> make moocow_install > > yup, I've understood that bit (and the motivations, I think). I meant > that since the problems arising in 'make moocow' appear to have been > *due to* clever & fiendish details of earlier scripts (e.g. use of > rsync > rather than svn, the cygwin/mingw dichotomy, etc. etc.), it would have > behooved me to have understood those scripts better (e.g. at all)... > >>>> Apparently, >>>> string2any and friends are still not getting built. In fact all >>>> of the >>>> 'moocow' is empty on Windows. > > This is still stumping me. The win32 build farm machine's > config.log is > showing me (for externals/moocow/locale): > > configure:2701: gcc \ > -DPD -O2 -mcpu=i586 -mtune=pentium3 \ > -I/home/pd/auto-build/pd-extended/pd/src \ > -Wall -W -ggdb \ > -I/home/pd/auto-build/pd-extended/Gem/src \ > -mms-bitfields \ > -DMSW -DNT -D'O_NONBLOCK=1' -D'srand48(n)=srand((n))' \ > -D'drand48()=((double)rand()/RAND_MAX)' -D'bzero(p,n)=memset(p,0,n)' \ > -L/home/pd/auto-build/pd-extended/pd/bin \ > conftest.c >&5 > <command line>:4:1: macro names must be identifiers > <command line>:5:1: macro names must be identifiers > <command line>:6:1: macro names must be identifiers > <command line>:7:1: macro names must be identifiers > configure:2704: $? = 1 > configure:2742: result: > configure: failed program was: > | /* confdefs.h. */ > | #define PACKAGE_NAME "locale" > | #define PACKAGE_TARNAME "locale" > | #define PACKAGE_VERSION "0.02-1" > | #define PACKAGE_STRING "locale 0.02-1" > | #define PACKAGE_BUGREPORT "moocow(a)ling.uni-potsdam.de" > | #define PACKAGE "locale" > | #define VERSION "0.02-1" > | /* end confdefs.h. */ > | > | int > | main () > | { > | > | ; > | return 0; > | } > configure:2749: error: C compiler cannot create executables > > ... newline escapes in the gcc call added post-hoc for legibility. > The > above call works fine (creating a.exe) by hand on the build farm win32 > machine with "/cygdrive/c/msys/1.0/bin:/cygdrive/c/MinGW/bin" > prepended > to PATH, so I can't grok where things might be going wrong, much less > what the "macro names must be identifiers" errors are all about -- > assumedly some of the '-D' flags are giving me grief, but since I > can't > reproduce the error, I can't tell which ones or what to do about it. > > Anyone have any ideas? Here's the trick: in the MSYS shell, where Pd is being built, / cygdrive/c/MinGW is actually mounted as /usr/local, so you want to use /usr/local/bin, etc. Usually autotools does that by default though, AFAIK. > I can't use rdesktop currently, since it's telling me I'd have to kick > out another user (pd). Oops, sorry, that was me. In the future, feel free to kick out the user if it has been more than an hour or so. .hc >>> In a related question, should the auto-build process for the win32 >>> build-farm machine be trying to build everything from the >>> LIB_TARGETS >>> variable in externals/Makefile? If so, then I must be being pretty >>> dense, because I can't see where my builds are getting called (I see >>> install calls, but no configuration or compilation), much less where >>> they might be failing... >> >> You are correct. Search for 'moocow_install:' in externals/Makefile. >> That's where its being called. > > Yes, right; but I couldn't see (until the rsync fix/hack was applied) > where the 'moocow' target was getting called, thus recursing into > externals/moocow/extended. That's showing up now, so no worries. > > marmosets, > Bryan > > -- > Bryan Jurish "There is *always* one more > bug." > jurish(a)ling.uni-potsdam.de -Lubarsky's Law of Cybernetic > Entomology > ---------------------------------------------------------------------------- If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson

1 0

PD Mem leaks WAS crash (memory leak?) with zexy?
by B. Bogart 24 Apr '09

24 Apr '09

Hello all, After more digging it appears that zexy is not causing a leak, but was just the last process to request memory. After using valgrind for some time it appears there are leaks all over the place. The reason I'm having trouble narrowing things down is simply that there are leaks in many different places. I've attached the full valgrind log, but here are some high(low?)lights: I was worried about my own gphoto code (not very well tested) which seems to loose about 41,968 bytes. This makes the following numbers much more worrisome: ==24879== 262,140 bytes in 1 blocks are definitely lost in loss record 220 of 229 ==24879== at 0x47F2D6E: malloc (vg_replace_malloc.c:207) ==24879== by 0xADB5A06: (within /usr/lib/libGL.so.173.14.09) ==24879== 2,142,184 (2,134,057 direct, 8,127 indirect) bytes in 956 blocks are definitely lost in loss record 225 of 229 ==24879== at 0x47F0E22: calloc (vg_replace_malloc.c:397) ==24879== by 0x80AD86D: getbytes (m_memory.c:24) ==24879== by 0xA7D6FFF: gemwin::createMess(_symbol*) (gemwin.cpp:141) ==24879== by 0xA7D70A6: gemwin::createMessCallback(void*, _symbol*) (gemwin.cpp:702) ==24879== by 0x80AA352: pd_typedmess (m_class.c:730) ==24879== 12,288,190 bytes in 10 blocks are definitely lost in loss record 228 of 229 ==24879== at 0x47F2D6E: malloc (vg_replace_malloc.c:207) ==24879== by 0x4D2EAA1: flext_root_single::operator new(unsigned) (in /usr/lib/pd/extra/py.pd_linux) ==24879== by 0x4D2F2DC: operator new[](unsigned) (in /usr/lib/pd/extra/py.pd_linux) ==24879== by 0xA7CA4A0: imageStruct::allocate(unsigned) (GemPixUtil.cpp:129) ==24879== by 0xA7C6D24: jpegImage2mem(char const*) (GemPixImageLoad.cpp:560) ==24879== by 0xA7C7999: image2mem(char const*) (GemPixImageLoad.cpp:192) ==24879== by 0xA8343F0: pix_buffer::openMess(_symbol*, int) (pix_buffer.cpp:201) ==24879== by 0xA833D74: pix_buffer::openMessCallback(void*, _symbol*, float) (pix_buffer.cpp:345) ==24879== by 0x80AA352: pd_typedmess (m_class.c:730) ==24879== 2,286,470,533 bytes in 1,849 blocks are possibly lost in loss record 229 of 229 ==24879== at 0x47F2D6E: malloc (vg_replace_malloc.c:207) ==24879== by 0x4D2EAA1: flext_root_single::operator new(unsigned) (in /usr/lib/pd/extra/py.pd_linux) ==24879== by 0x4D2F2DC: operator new[](unsigned) (in /usr/lib/pd/extra/py.pd_linux) ==24879== by 0xA7CA4A0: imageStruct::allocate(unsigned) (GemPixUtil.cpp:129) ==24879== by 0xA7C6D24: jpegImage2mem(char const*) (GemPixImageLoad.cpp:560) ==24879== by 0xA7C7999: image2mem(char const*) (GemPixImageLoad.cpp:192) ==24879== by 0xA862149: pix_image::openThread(void*) (pix_image.cpp:167) ==24879== by 0x48464BF: start_thread (in /lib/i686/cmov/libpthread-2.7.so) ==24879== by 0x4C8C6DD: clone (in /lib/i686/cmov/libc-2.7.so) I'm cross-posting to gem-dev since a few of these big ticket leaks appear to be in Gem. I'm currently testing with pd-0.39-2 (as I was able to use this in a previous installation without any noticeable leakage). I also tried pd-0.40-3 and pd-0.42-4. I'm currently using r 2750 of Gem from SVN. I also tried the current version of Gem from SVN, but that did not appear to solve the issue. Any any of these definite, or possible leaks known and I'm just missing the fix? Any recommendations on how I can minimize the effect of these leaks? All this has made me think perhaps an installation version of PD+crucial externals would be useful, that is one that is tested for extremely long periods and does not change very often. Any advice appreciated. Thanks, B. Bogart

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev April 2009