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://grrrr.org