[PD] flext, fluid~, readanysf~, and FLEXT_USE_CMEM (or don't)
morning all, I've been chasing a bug for several weeks now that I just can't seem to get my head around: symptoms are segfaults and complete crashes in pd (v0.40-2 vanilla) on linux/x86 [debian unstable, gcc 4.1.2]. gdb backtraces are available, and I've just recompiled using identical CFLAGS everywhere (-O3 -march=pentium-m -msse -msse2 -mfpmath=sse -ffast-math -funroll-loops), since I had feared that -malign-double might have been biting me, but this doesn't appear to have been the case... Buglet the First (solved, kinda) === - description: [pool] and [readanysf~] don't play nicely together - symptom: the (infamous) libc message on stderr when closing a patch: *** glibc detected *** free(): invalid pointer: 0x0823e46c *** + apparently caused by some goofiness with the flext delete() operator (backtraces etc. available) - solution (I think, thanks to the list archives): + compile both flext and readanysf~ with -DFLEXT_USE_CMEM + readanysf~ really seems to need FLEXT_USE_CMEM flext-globally (I can provide a pretty complete and systematic list of the configurations I've tried: it's possible to compile and run successfully without FLEXT_USE_CMEM, but things break more or less randomly at runtime then: particularly, the "stop" message to readanysf~ segfaults pd) - solution (I think, thanks to the list archives): + this seems to work for [pool] and [readanysf~], but... Buglet the Second (please assist!) === - description: [fluid~] in abstractions crashes pd + having compiled flext with -DFLEXT_USE_CMEM, loading any abstraction containing a [fluid~] object causes pd to segfault (see below) + bug occurs even without any other externals loaded + oddly, I *can* create [fluid~]s by hand, (but not load them in an abstraction, which makes the object pretty useless, im(ns)ho) + any ideas why fluid_init() is trying to initialize this==NULL ? - this appears to be FLEXT_USE_CMEM related, since I didn't get these symptoms without FLEXT_USE_CMEM in flext itself + I can't just -UFLEXT_USE_CMEM for fluid~, because: (a) that would break readanysf~ if I did it flext-globally, and (b) if I undefine FLEXT_USE_CMEM only for fluid~, I get undefined linker symbols at runtime: /usr/local/lib/pd/extra/fluid~.pd_linux: \ /usr/local/lib/pd/extra/fluid~.pd_linux: undefined symbol: \ _ZN19flext_root_single_ddlEPv \ fluid~: can't load library + would it help to fork the flext build procedure (again!), basically adding another library suffix for FLEXT_USE_CMEM, since its effects appear not to be restricted to the headers? - if the suffix were, say, 'c', where we now have: libflext-pd((_d)?.so|_[st]d?.a) we would get: libflext-pd((_c?d?).so|_[st]c?d?.a) - i know this is ugly, and I'm not even sure it would work, but I'm at my wits' end here... I hope somebody can shed some light on this for me... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210693952 (LWP 24068)] 0xb7dcb589 in free () from /lib/tls/i686/cmov/libc.so.6 (gdb) backtrace #0 0xb7dcb589 in free () from /lib/tls/i686/cmov/libc.so.6 #1 0xb7d1e639 in delete_fluid_synth () from /usr/lib/libfluidsynth.so.1 #2 0x08237bd0 in ?? () #3 0x0811ace0 in mstack.5434 () #4 0xbfd76828 in ?? () #5 0xb7d47366 in fluid::fluid_init (this=0x0, argc=-1210746848, argv=0xb7caf730) at fluid/main.cpp:251 Previous frame inner to this frame (corrupt stack?) marmosets, Bryan ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] flext, fluid~, readanysf~, and FLEXT_USE_CMEM (or don't)
Hi Bryan, i think it would be a good idea to define FLEXT_USE_CMEM in the flext build system by default. Currently pd doesn't use anything different than C memory allocation (in getbytes, freebytes) so there's no real reason to not to. Concerning your fluid problems i can't really help, since i don't use it, but i'm sure there are some experts who can. all the best, Thomas Am 28.01.2007 um 17:17 schrieb Bryan Jurish: morning all, I've been chasing a bug for several weeks now that I just can't seem to get my head around: symptoms are segfaults and complete crashes in pd (v0.40-2 vanilla) on linux/x86 [debian unstable, gcc 4.1.2]. gdb backtraces are available, and I've just recompiled using identical CFLAGS everywhere (-O3 -march=pentium-m -msse -msse2 -mfpmath=sse -ffast-math -funroll-loops), since I had feared that -malign-double might have been biting me, but this doesn't appear to have been the case... Buglet the First (solved, kinda) === - description: [pool] and [readanysf~] don't play nicely together - symptom: the (infamous) libc message on stderr when closing a patch: *** glibc detected *** free(): invalid pointer: 0x0823e46c *** + apparently caused by some goofiness with the flext delete() operator (backtraces etc. available) - solution (I think, thanks to the list archives): + compile both flext and readanysf~ with -DFLEXT_USE_CMEM + readanysf~ really seems to need FLEXT_USE_CMEM flext-globally (I can provide a pretty complete and systematic list of the configurations I've tried: it's possible to compile and run successfully without FLEXT_USE_CMEM, but things break more or less randomly at runtime then: particularly, the "stop" message to readanysf~ segfaults pd) - solution (I think, thanks to the list archives): + this seems to work for [pool] and [readanysf~], but... Buglet the Second (please assist!) === - description: [fluid~] in abstractions crashes pd + having compiled flext with -DFLEXT_USE_CMEM, loading any abstraction containing a [fluid~] object causes pd to segfault (see below) + bug occurs even without any other externals loaded + oddly, I *can* create [fluid~]s by hand, (but not load them in an abstraction, which makes the object pretty useless, im(ns)ho) + any ideas why fluid_init() is trying to initialize this==NULL ? - this appears to be FLEXT_USE_CMEM related, since I didn't get these symptoms without FLEXT_USE_CMEM in flext itself + I can't just -UFLEXT_USE_CMEM for fluid~, because: (a) that would break readanysf~ if I did it flext-globally, and (b) if I undefine FLEXT_USE_CMEM only for fluid~, I get undefined linker symbols at runtime: /usr/local/lib/pd/extra/fluid~.pd_linux: \ /usr/local/lib/pd/extra/fluid~.pd_linux: undefined symbol: \ _ZN19flext_root_single_ddlEPv \ fluid~: can't load library + would it help to fork the flext build procedure (again!), basically adding another library suffix for FLEXT_USE_CMEM, since its effects appear not to be restricted to the headers? - if the suffix were, say, 'c', where we now have: libflext-pd((_d)?.so|_[st]d?.a) we would get: libflext-pd((_c?d?).so|_[st]c?d?.a) - i know this is ugly, and I'm not even sure it would work, but I'm at my wits' end here... I hope somebody can shed some light on this for me... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210693952 (LWP 24068)] 0xb7dcb589 in free () from /lib/tls/i686/cmov/libc.so.6 (gdb) backtrace #0 0xb7dcb589 in free () from /lib/tls/i686/cmov/libc.so.6 #1 0xb7d1e639 in delete_fluid_synth () from /usr/lib/ libfluidsynth.so.1 #2 0x08237bd0 in ?? () #3 0x0811ace0 in mstack.5434 () #4 0xbfd76828 in ?? () #5 0xb7d47366 in fluid::fluid_init (this=0x0, argc=-1210746848, argv=0xb7caf730) at fluid/main.cpp:251 Previous frame inner to this frame (corrupt stack?) marmosets, Bryan ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list Thomas Grill http://g.org ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] flext, fluid~, readanysf~, and FLEXT_USE_CMEM (or don't)
Hi Bryan, Thomas, I think I have the same problem as you. My external crashes when I try to delete the object from the canvas i.e when the destructor of my external is called. The BT is #0 0xb7db0334 in free () from /lib/tls/i686/cmov/libc.so.6 #1 0xb72858b1 in operator delete (ptr=0x0) at ../../../../src/libstdc++-v3/libsupc++/del_op.cc:49 #2 0xb72da0d1 in Mixer::~Mixer () from /usr/lib/libsndobj.so.2 #3 0xb733383b in resoncomb::FreeObjs () from /usr/lib/pd/extra/resoncomb~.pd_linux #4 0xb733f4af in flext_sndobj::ClearObjs () from /usr/lib/pd/extra/resoncomb~.pd_linux #5 0xb733f5e8 in flext_sndobj::Exit () from /usr/lib/pd/extra/resoncomb~.pd_linux #6 0xb733549f in flext_obj_single::obj_free () from /usr/lib/pd/extra/resoncomb~.pd_linux I tried adding '#define FLEXT_USE_CMEM' to the top of flext.h. I rebuilt flext and installed it. I also added the define to the top of my own external and rebuilt it. No joy ;( Firstly is this/are these the correct place(s) to define FLEXT_USE_CMEM ? Thomas while looking over the Flext docs I came across this : "Some few external libraries have troubles with flext's global new and delete overloadings. In these cases one can switch back to the C library memory operators by defining the FLEXT_NOGLOBALNEW macro before inclusion of the flext.h header file (e.g. as a -D compiler option)" Again where should this FLEXT_NOGLOBALNEW be defined? in the package.txt ? (Sorry I am by no means experienced with this native stuff). Would this bug be related to the problem I am experiencing. The exception is thrown on a delete of SndObj pointer. I have already talked to Victor and he has never seen anything like this before. So frustrating, I have finished my first PD external (Multi stereo comb filter) and I want to release it properly but I can't with this bug in it !!! Conor Thomas Grill wrote: >Hi Bryan, >i think it would be a good idea to define FLEXT_USE_CMEM in the flext >build system by default. >Currently pd doesn't use anything different than C memory allocation >(in getbytes, freebytes) so there's no real reason to not to. >Concerning your fluid problems i can't really help, since i don't use >it, but i'm sure there are some experts who can. >all the best, >Thomas Am 28.01.2007 um 17:17 schrieb Bryan Jurish: > morning all, > > I've been chasing a bug for several weeks now that I just can't > seem to > get my head around: symptoms are segfaults and complete crashes in pd > (v0.40-2 vanilla) on linux/x86 [debian unstable, gcc 4.1.2]. gdb > backtraces are available, and I've just recompiled using identical > CFLAGS everywhere (-O3 -march=pentium-m -msse -msse2 -mfpmath=sse > -ffast-math -funroll-loops), since I had feared that -malign-double > might have been biting me, but this doesn't appear to have been the > case... > > Buglet the First (solved, kinda) > === > - description: [pool] and [readanysf~] don't play nicely together > - symptom: the (infamous) libc message on stderr when closing a patch: > *** glibc detected *** free(): invalid pointer: 0x0823e46c *** > + apparently caused by some goofiness with the flext delete() > operator > (backtraces etc. available) > - solution (I think, thanks to the list archives): > + compile both flext and readanysf~ with -DFLEXT_USE_CMEM > + readanysf~ really seems to need FLEXT_USE_CMEM flext-globally > (I can > provide a pretty complete and systematic list of the configurations > I've > tried: it's possible to compile and run successfully without > FLEXT_USE_CMEM, but things break more or less randomly at runtime > then: > particularly, the "stop" message to readanysf~ segfaults pd) > - solution (I think, thanks to the list archives): > + this seems to work for [pool] and [readanysf~], but... > > > Buglet the Second (please assist!) > === > - description: [fluid~] in abstractions crashes pd > + having compiled flext with -DFLEXT_USE_CMEM, loading any > abstraction > containing a [fluid~] object causes pd to segfault (see below) > + bug occurs even without any other externals loaded > + oddly, I *can* create [fluid~]s by hand, (but not load them in > an abstraction, which makes the object pretty useless, im(ns)ho) > + any ideas why fluid_init() is trying to initialize this==NULL ? > - this appears to be FLEXT_USE_CMEM related, since I didn't get > these symptoms without FLEXT_USE_CMEM in flext itself > + I can't just -UFLEXT_USE_CMEM for fluid~, because: > (a) that would break readanysf~ if I did it flext-globally, and > (b) if I undefine FLEXT_USE_CMEM only for fluid~, I get undefined > linker symbols at runtime: > > /usr/local/lib/pd/extra/fluid~.pd_linux: \ > /usr/local/lib/pd/extra/fluid~.pd_linux: undefined symbol: \ > _ZN19flext_root_single_ddlEPv \ > fluid~: can't load library > > + would it help to fork the flext
Re: [PD] flext, fluid~, readanysf~, and FLEXT_USE_CMEM (or don't)
morning Conor, comments below... On 2007-02-02 23:18:35, Conor J Curran <[EMAIL PROTECTED]> appears to have written: > Hi Bryan, Thomas, > > I think I have the same problem as you. you have my deepest, most heartfelt sympathy. have a beer. > My external crashes when I try > to delete the object from the canvas i.e when the destructor of my > external is called. The BT is > > #0 0xb7db0334 in free () from /lib/tls/i686/cmov/libc.so.6 > #1 0xb72858b1 in operator delete (ptr=0x0) > at ../../../../src/libstdc++-v3/libsupc++/del_op.cc:49 ... aye, there's the rub -- what's the deal with calling delete() (or in the case of fluid~, fluid_init() via new()) on this==NULL? I've looked a bit at both Thomas' and Frank's code now, and I just can't see where it's coming from, unless it's some thread-related black magic involving memory locking, but that's an unconfirmed hypothesis at this point, since I've never yet worked with threads myself... > #2 0xb72da0d1 in Mixer::~Mixer () from /usr/lib/libsndobj.so.2 > #3 0xb733383b in resoncomb::FreeObjs () >from /usr/lib/pd/extra/resoncomb~.pd_linux > #4 0xb733f4af in flext_sndobj::ClearObjs () >from /usr/lib/pd/extra/resoncomb~.pd_linux > #5 0xb733f5e8 in flext_sndobj::Exit () >from /usr/lib/pd/extra/resoncomb~.pd_linux > #6 0xb733549f in flext_obj_single::obj_free () >from /usr/lib/pd/extra/resoncomb~.pd_linux > > I tried adding '#define FLEXT_USE_CMEM' to the top of flext.h. I rebuilt > flext and installed it. I also added the define to the top of my own > external and rebuilt it. No joy ;( > Firstly is this/are these the correct place(s) to define > FLEXT_USE_CMEM ? Well, I added -DFLEXT_USE_CMEM to the UFLAGS variable in flext/buildsys/config-lnx-pd-gcc.txt. That way, I'm sure to get the variable defined for all objects using the flext build system. For readanysf~ (which uses autoconf/automake), I think I added the flac (and several other hacks) to my CFLAGS (and hacked configure.in to respect my CFLAGS jeez, why the bejeebers do people always clobber the user variable instead of using the designated AM_CFLAGS? *grrr*, re-ran automake, autoconf, and configure, and made 'clean all' [repeat ca. 20 times for various hacks]. If I get it working stably at any point, I'll check the relevant changes as AC_ARG_WITH options into cvs ;-) Just for the record, I did in fact get flext, fluid~, and readanysf~ to make a kind of peace with one another by compiling 2 separate and distinct versions of the (static) flext libraries (as I sketched in my original mail), linking readanysf~ with libflext-pd_tc.a and everything else with libflext-pd.so (flext build.sh "release-shared" mode). Something however remains foul, since I still get segfaults in truly bizarre and complicated cases involving multiple subpatches, some switch~ logic, and an array re-allocation with [arraysize]: for now, I just made the problem go away by uncompressing all my samples and rolling back to an old version of the patch which uses sfread~ (fortunately, my abstractions live in a private cvs repository, so that part was easy)... > Thomas while looking over the Flext docs I came across this : > > "Some few external libraries have troubles with flext's global new and > delete overloadings. In these cases one can switch back to the C library > memory operators by defining the FLEXT_NOGLOBALNEW macro before > inclusion of the flext.h header file (e.g. as a -D compiler option)" > > Again where should this FLEXT_NOGLOBALNEW be defined? in the > package.txt ? (Sorry I am by no means experienced with this native > stuff). I think I can help you there: FLEXT_NOGLOBALNEW appears to do nothing more or less than cause FLEXT_USE_CMEM to be defined, whilst spitting out a warning message that the "FLEXT_NOGLOBALNEW" macro is deprecated. > Would this bug be related to the problem I am experiencing. The > exception is thrown on a delete of SndObj pointer. I have already talked > to Victor and he has never seen anything like this before. First, make sure you're not really delete()ing a NULL pointer ;-) That said, I do think we've stumbled onto the same bug, and that there's something going horribly wrong (possibly because of mis-use and/or misunderstanding of flext's conventions) particularly when flext objects are not self-contained, and call functions from 3rd-party shared libraries (e.g. fluid~ --> libfluid; readanysf~ --> libogg, libvorbis, libmad, libflac, etc.; your resoncomb~ --> libSndObj). I suspect that the real crux is probably thread- (and therefore lock-)related, since in both our cases, the crashes seem to be occurring in functions which I deem likely to be doing some pretty heavy-duty memory manipulation (fluid_init() probably calls malloc() [I haven't checked, but it seems likely], and SndObj's Mixer::~Mixer() is definitely calling delete()). This looks to me at the moment as if it might have to do with a conditional I don't fully understand in flsupport.cpp at ar
Re: [PD] flext, fluid~, readanysf~, and FLEXT_USE_CMEM (or don't)
Hallo, Bryan Jurish hat gesagt: // Bryan Jurish wrote: > First, make sure you're not really delete()ing a NULL pointer ;-) That > said, I do think we've stumbled onto the same bug, and that there's > something going horribly wrong (possibly because of mis-use and/or > misunderstanding of flext's conventions) particularly when flext objects > are not self-contained, and call functions from 3rd-party shared > libraries (e.g. fluid~ --> libfluid; readanysf~ --> libogg, libvorbis, > libmad, libflac, etc.; your resoncomb~ --> libSndObj). Hm, maybe fluid~ should go back to being a pure C/Pd external like it was in its prevous life as iiwu~? Max-users didn't seem interested in it (or just not willing to compile) anyways, one even wrote a new, pure C Max external for fluidsynth instead of compiling the flext-fluid~. So the cross-platformness I was hoping to achieve didn't work out in practice. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] flext, fluid~, readanysf~, and FLEXT_USE_CMEM (or don't)
hello,
for those who are interested in to use fluid~ with soundfont
instruments under OSX, here it is the before -flext compiled
fluid~.pd_darwin file. It works fine in my machine under OSX 10.4.8
and Pd-0.39.2-extended-test7, but I never tried with any other machine.
http://www.puredata.org/Members/korayt/pdfiles/fluid~pd_darwin.tgz/
Koray.
-
M.Koray Tahiroglu
Media Lab,UIAH
http://mlab.uiah.fi/~korayt/
tel: +358 50 939 02 33 ( in Finland only)
tel: +90 533 712 8245
On Feb 3, 2007, at 1:00 PM, [EMAIL PROTECTED] wrote:
Message: 8
Date: Sat, 3 Feb 2007 10:32:44 +0100
From: Frank Barknecht <[EMAIL PROTECTED]>
Subject: Re: [PD] flext, fluid~, readanysf~, and FLEXT_USE_CMEM (or
don't)
To: pd-list@iem.at
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
Hallo,
Bryan Jurish hat gesagt: // Bryan Jurish wrote:
First, make sure you're not really delete()ing a NULL pointer ;-)
That
said, I do think we've stumbled onto the same bug, and that there's
something going horribly wrong (possibly because of mis-use and/or
misunderstanding of flext's conventions) particularly when flext
objects
are not self-contained, and call functions from 3rd-party shared
libraries (e.g. fluid~ --> libfluid; readanysf~ --> libogg,
libvorbis,
libmad, libflac, etc.; your resoncomb~ --> libSndObj).
Hm, maybe fluid~ should go back to being a pure C/Pd external like it
was in its prevous life as iiwu~? Max-users didn't seem interested in
it (or just not willing to compile) anyways, one even wrote a new,
pure C Max external for fluidsynth instead of compiling the
flext-fluid~. So the cross-platformness I was hoping to achieve didn't
work out in practice.
Ciao
--
Frank Barknecht _ __footils.org_ __goto10.org__
--
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] flext, fluid~, readanysf~, and FLEXT_USE_CMEM (or don't)
sorry for misinformation in the previous email, but this was also
compiled under Flext (probably done with the version 0.4.0 or 0.4.1 I
am not sure anymore), and it works with fluidsynth-1.0.6.
Koray.
-
M.Koray Tahiroglu
Media Lab,UIAH
http://mlab.uiah.fi/~korayt/
tel: +358 50 939 02 33 ( in Finland only)
tel: +90 533 712 8245
On Feb 3, 2007, at 2:07 PM, Koray Tahiroglu wrote:
hello,
for those who are interested in to use fluid~ with soundfont
instruments under OSX, here it is the before -flext compiled
fluid~.pd_darwin file. It works fine in my machine under OSX
10.4.8 and Pd-0.39.2-extended-test7, but I never tried with any
other machine.
http://www.puredata.org/Members/korayt/pdfiles/fluid~pd_darwin.tgz/
Koray.
-
M.Koray Tahiroglu
Media Lab,UIAH
http://mlab.uiah.fi/~korayt/
tel: +358 50 939 02 33 ( in Finland only)
tel: +90 533 712 8245
On Feb 3, 2007, at 1:00 PM, [EMAIL PROTECTED] wrote:
Message: 8
Date: Sat, 3 Feb 2007 10:32:44 +0100
From: Frank Barknecht <[EMAIL PROTECTED]>
Subject: Re: [PD] flext, fluid~, readanysf~, and FLEXT_USE_CMEM (or
don't)
To: pd-list@iem.at
Message-ID: <[EMAIL PROTECTED]>
Content-Type: text/plain; charset=us-ascii
Hallo,
Bryan Jurish hat gesagt: // Bryan Jurish wrote:
First, make sure you're not really delete()ing a NULL
pointer ;-) That
said, I do think we've stumbled onto the same bug, and that there's
something going horribly wrong (possibly because of mis-use and/or
misunderstanding of flext's conventions) particularly when flext
objects
are not self-contained, and call functions from 3rd-party shared
libraries (e.g. fluid~ --> libfluid; readanysf~ --> libogg,
libvorbis,
libmad, libflac, etc.; your resoncomb~ --> libSndObj).
Hm, maybe fluid~ should go back to being a pure C/Pd external like it
was in its prevous life as iiwu~? Max-users didn't seem
interested in
it (or just not willing to compile) anyways, one even wrote a new,
pure C Max external for fluidsynth instead of compiling the
flext-fluid~. So the cross-platformness I was hoping to achieve
didn't
work out in practice.
Ciao
--
Frank Barknecht _ __footils.org_ __goto10.org__
--
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] flext, fluid~, readanysf~, and FLEXT_USE_CMEM (or don't)
On Sat, 2007-02-03 at 10:32 +0100, Frank Barknecht wrote: > > > First, make sure you're not really delete()ing a NULL pointer ;-) > That > > said, I do think we've stumbled onto the same bug, and that there's > > something going horribly wrong (possibly because of mis-use and/or > > misunderstanding of flext's conventions) particularly when flext > objects > > are not self-contained, and call functions from 3rd-party shared > > libraries (e.g. fluid~ --> libfluid; readanysf~ --> libogg, > libvorbis, > > libmad, libflac, etc.; your resoncomb~ --> libSndObj). > > Hm, maybe fluid~ should go back to being a pure C/Pd external like it > was in its prevous life as iiwu~? Max-users didn't seem interested in > it (or just not willing to compile) anyways, one even wrote a new, > pure C Max external for fluidsynth instead of compiling the > flext-fluid~. So the cross-platformness I was hoping to achieve didn't > work out in practice. the overloading of the memory allocation functions in flext seems to be only a problem on linux (iirc, thomas could never really reproduce it on osx/windows). i've had the same problems one or two years ago, and for me i fixed it, by writing my own custom scons build system for flext/flexternals, that enforces same preprocessor definitons on _all_ externals and ensures the rebuilding of objects, in case of header file changes. cheers ... tim -- [EMAIL PROTECTED]ICQ: 96771783 http://www.mokabar.tk Avoid the world, it's just a lot of dust and drag and means nothing in the end. Jack Kerouac signature.asc Description: This is a digitally signed message part ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] flext, fluid~, readanysf~, and FLEXT_USE_CMEM (or don't)
moin Conor,
On 2007-02-06 00:50:17, Conor J Curran <[EMAIL PROTECTED]> appears to
have written:
> Hi Bryan
> Thanks for the help on this.
>
> I added this as you specified above but now when I try to load the patch
> which contains the external PD crashes. It is somewhat sporadic. I then
> recompiled a debug version of the external. I narrowed down my problem
> now to when there are more than one flext external open in the patch.
> The patch will not open if this is the case. (Bryan's problem number
> two - I'm playing catch up;-).
sounds familiar indeed... have you by any chance tried compiling your
external without threads, linking (statically) to libflext-pd_s.a ? I
don't know if you need threads or not, but at least that might narrow
down the range of possible error sources...
> BTrace from a crash on start up.
> #0 0x007d0f00 in ?? ()
> #1 0xb7ea32c0 in __free_tcb () from /lib/tls/i686/cmov/libpthread.so.0
> #2 0x0001 in ?? ()
> #3 0xb7dd4186 in calloc () from /lib/tls/i686/cmov/libc.so.6
> Previous frame inner to this frame (corrupt stack?)
>
> Next below is the GDB trace when I attempt to attach GDB to PD after
> previously manually the external symbols by hand to GDB. I don't know if
> this has anything to do with it:
>
> `system-supplied DSO at 0xe000' has disappeared; keeping its
> symbols.
> warning: Cannot initialize thread debugging library: unknown thread_db
> error '22'
> warning: Cannot initialize thread debugging library: unknown thread_db
> error '22'
I've seen something like this too; but am not sure what it means :-/
> Next is the trace (out to terminal)from PD when the external is managed
> to be loaded properly deleted.
>
> invalid command name ".x82578d0.c"
I see these more frequently than I'd like to admit: my guess is that
these are errors from Tk ("invalid command name" is a Tcl/Tk error)
caused by pd-gui objects which have ceased to exist but which for some
reason are still hooked up to at least one Tk callback. Not dangerous
as such, but indicative of something goofy going on somewhere.
> And finally the BT when the patch is attempted to be opened with two
> externals present.
>
> #0 0xe410 in __kernel_vsyscall ()
> #1 0xb7e844c3 in ?? () from /lib/tls/i686/cmov/libpthread.so.0
> #2 0x08230d18 in ?? ()
> #3 0x080ffebc in oss_send_dacs ()
> #4 0x0810dbd1 in _IO_stdin_used ()I would really like to get on to
> building another external asap.
> #5 0xbffab684 in ?? ()
> #6 0xbffab638 in ?? ()
> #7 0x38fd in ?? ()
> #8 0xbffab54c in ?? ()
> #9 0x0810dbd1 in _IO_stdin_used ()
... I'd try it without FLEXT_THREADS (libpthread), both with and without
FLEXT_USE_CMEM: that might make things clearer. I think this can be
accomplished by:
(a) ensuring that FLEXT_THREADS is undefined for your external
(-UFLEXT_THREADS)
(b) linking to the static single-threaded flext library, libflext-pd_s.a
... hmm, looking at it, it seems that the default shared libflext-pd.so
is threadless, but is nonetheless compiled and linked with the -pthread
option. Maybe it might help to remove the "-pthread" compiler & linker
flags for threadless (shared,single) builds: this amounts to editing
flext/buildsys/lnx/gnumake-gcc.inc, and the idea is just a shot in the
dark, but at least it would make debugging easier ;-)
marmosets,
Bryan
--
Bryan Jurish "There is *always* one more bug."
[EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology
___
PD-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
Re: [PD] flext, fluid~, readanysf~, and FLEXT_USE_CMEM (or don't)
Hola Bryan, > sounds familiar indeed... have you by any chance tried compiling your > external without threads, linking (statically) to libflext-pd_s.a ? I > don't know if you need threads or not, but at least that might narrow > down the range of possible error sources... I have not but I was under the impression that if I was to compile my external in the current flext setup using single-release. This would imply no use of threads and also statically linking to the .a lib as opposed to the .so. Is this correct? If not what do I need to do to ensure I do so? Sorry but I might have mentioned before I pretty clueless with this gcc stuff. > ... I'd try it without FLEXT_THREADS (libpthread), both with and without > FLEXT_USE_CMEM: that might make things clearer. I think this can be > accomplished by: > > (a) ensuring that FLEXT_THREADS is undefined for your external > (-UFLEXT_THREADS) Should -UFLEXT_THREADS be added to my config.txt in the external directory. UFLAGS += -UFLEXT_THREADS ? Or should I ensure it is no defined. -U = undefine ? > (b) linking to the static single-threaded flext library, libflext-pd_s.a > ... hmm, looking at it, it seems that the default shared libflext-pd.so > is threadless, but is nonetheless compiled and linked with the -pthread > option. Maybe it might help to remove the "-pthread" compiler & linker > flags for threadless (shared,single) builds: this amounts to editing > flext/buildsys/lnx/gnumake-gcc.inc, and the idea is just a shot in the > dark, but at least it would make debugging easier ;-) I have edited this file so now the part which did contain the pthread stuff looks like this ## #removed from both: -pthread CFLAGS += -fPIC LDFLAGS += -shared One question are you working from 5.0 release of flext or are you using the head of cvs? I will have some more time to spend on this tomorrow evening. until the morning. Cj > marmosets, > Bryan > ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: [PD] flext, fluid~, readanysf~, and FLEXT_USE_CMEM (or don't)
moin Conor, On 2007-02-07 01:12:05, Conor J Curran <[EMAIL PROTECTED]> appears to have written: >> sounds familiar indeed... have you by any chance tried compiling your >> external without threads, linking (statically) to libflext-pd_s.a ? I >> don't know if you need threads or not, but at least that might narrow >> down the range of possible error sources... > I have not but I was under the impression that if I was to compile my > external in the current flext setup using single-release. This would imply no > use of threads and also statically linking to the .a lib as opposed to the > .so. > Is this correct? If not what do I need to do to ensure I do so? Sorry > but I might have mentioned before I pretty clueless with this gcc stuff. yep, afaik any -single build should produce a threadless (the official term in Thomas' documentation appears to be "single-threaded") version; at least, the flext build system won't define FLEXT_THREADS for *-single builds. Just make sure you're not defining it yourself ;-) >> ... I'd try it without FLEXT_THREADS (libpthread), both with and without >> FLEXT_USE_CMEM: that might make things clearer. I think this can be >> accomplished by: >> >> (a) ensuring that FLEXT_THREADS is undefined for your external >> (-UFLEXT_THREADS) > Should -UFLEXT_THREADS be added to my config.txt in the external > directory. > > UFLAGS += -UFLEXT_THREADS ? > Or should I ensure it is no defined. -U = undefine ? If you're not defining it (e.g. with -DFLEXT_THREADS or with a #define in some source file), then you're ok: it won't be defined by flext build.sh for a *-single build. >> Maybe it might help to remove the "-pthread" compiler & linker >> flags for threadless (shared,single) builds: this amounts to editing >> flext/buildsys/lnx/gnumake-gcc.inc, and the idea is just a shot in the >> dark, but at least it would make debugging easier ;-) > I have edited this file so now the part which did contain the pthread > stuff looks like this > ## > #removed from both: -pthread > CFLAGS += -fPIC > LDFLAGS += -shared yep, that's the bit I meant. As I noted yesterday, my fluid~ problems were due to a missing initialization / assumed zero-initialization of the object's memory, which resulted in an attempt to free() a pointer of basically random junk (either unallocated or allocated by a different program or thread or whatever)... According to the gcc docs: -pthread Add support for multithreading using the POSIX threads library. This option sets flags for both the preprocessor and linker. It does not affect the thread safety of object code produced by the compiler or that of libraries supplied with it. These are HP-UX specific flags. ... there are -pthread flags listed for other architectures too, and gcc doesn't complain about the flags, but I haven't yet found any docs for the -pthread option on x86, so maybe it doesn't do anything at all here except maybe link to libpthread... > One question are you working from 5.0 release of flext or are you using > the head of cvs? I'm using the head of cvs, and I haven't actually removed the "-pthread" from my build flags here. Of course, I am still getting bizarre crashes & lockups, but not the fluid~-related ones. marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
fluid~ bug (was: [PD] flext, fluid~, readanysf~, and FLEXT_USE_CMEM (or don't))
morning all, I take it all back and assert the opposite! Regarding the following fluid~ error: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1210693952 (LWP 24068)] 0xb7dcb589 in free () from /lib/tls/i686/cmov/libc.so.6 (gdb) backtrace #0 0xb7dcb589 in free () from /lib/tls/i686/cmov/libc.so.6 #1 0xb7d1e639 in delete_fluid_synth () from /usr/lib/ libfluidsynth.so.1 #2 0x08237bd0 in ?? () #3 0x0811ace0 in mstack.5434 () #4 0xbfd76828 in ?? () #5 0xb7d47366 in fluid::fluid_init (this=0x0, argc=-1210746848, argv=0xb7caf730) at fluid/main.cpp:251 Previous frame inner to this frame (corrupt stack?) This is just a plain old initialization bug in fluid/main.cpp. It seems that fluid::fluid() calls fluid::fluid_init(), which calls libfluidsynth's delee_fluid_synth() if (this->synth != NULL), which is complete and utter hogwash at initialization time unless this->synth has been initialized to NULL, which (apparently) happens just in case we're using flext's new() and delete() (!defined(FLEXT_USE_CMEM)) rather than pd's getbytes() (defined(FLEXT_USE_CMEM)), so: Frank, would you have anything against my chaning line 51 of fluid/main.cpp in CVS from: fluid(int argc, t_atom *argv) to: fluid(int argc, t_atom *argv) : synth(NULL) ? Finding this one at least makes me feel somewhat better, although readanysf~ is still giving me headaches... marmosets, Bryan -- Bryan Jurish "There is *always* one more bug." [EMAIL PROTECTED] -Lubarsky's Law of Cybernetic Entomology ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Re: fluid~ bug (was: [PD] flext, fluid~, readanysf~, and FLEXT_USE_CMEM (or don't))
Hallo, Bryan Jurish hat gesagt: // Bryan Jurish wrote: > This is just a plain old initialization bug in fluid/main.cpp. It seems > that fluid::fluid() calls fluid::fluid_init(), which calls > libfluidsynth's delee_fluid_synth() if (this->synth != NULL), which is > complete and utter hogwash at initialization time unless this->synth has > been initialized to NULL, which (apparently) happens just in case we're > using flext's new() and delete() (!defined(FLEXT_USE_CMEM)) rather than > pd's getbytes() (defined(FLEXT_USE_CMEM)), so: > > Frank, would you have anything against my chaning line 51 of > fluid/main.cpp in CVS from: > > fluid(int argc, t_atom *argv) > > to: > > fluid(int argc, t_atom *argv) : synth(NULL) > > ? Yes, you're right of course. How could this fly under the rader for so long... Your fix is commited, thanks a lot. Ciao -- Frank Barknecht _ __footils.org_ __goto10.org__ ___ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
