Buglet the First (solved, kinda)

28 Jan 2007 · *can*

      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

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

Buglet the First (solved, kinda)

Buglet the Second (please assist!)

Buglet the First (solved, kinda)

Buglet the Second (please assist!)