moin Conor,
On 2007-02-06 00:50:17, Conor J Curran forward@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