[PD] flext, fluid~, readanysf~, and FLEXT_USE_CMEM (or don't)

[Conor J Curran]

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 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
>