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

[Bryan Jurish]

moin Conor,

On 2007-02-06 00:50:17, Conor J Curran <forward at forwind.net> 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  0x00000001 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 0xffffe000' 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  0xffffe410 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  0x380000fd 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."
jurish at ling.uni-potsdam.de      -Lubarsky's Law of Cybernetic Entomology