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
Hola Bryan,
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...
I have not but I was under the impression that if I was to compile my external in the current flext setup using single-release. This would imply no use of threads and also statically linking to the .a lib as opposed to the .so. Is this correct? If not what do I need to do to ensure I do so? Sorry but I might have mentioned before I pretty clueless with this gcc stuff.
... 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)
Should -UFLEXT_THREADS be added to my config.txt in the external directory.
UFLAGS += -UFLEXT_THREADS ? Or should I ensure it is no defined. -U = undefine ?
(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 ;-)
I have edited this file so now the part which did contain the pthread stuff looks like this ############################################## #removed from both: -pthread CFLAGS += -fPIC LDFLAGS += -shared
One question are you working from 5.0 release of flext or are you using the head of cvs?
I will have some more time to spend on this tomorrow evening.
until the morning.
Cj
marmosets, Bryan
moin Conor,
On 2007-02-07 01:12:05, Conor J Curran forward@forwind.net appears to have written:
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...
I have not but I was under the impression that if I was to compile my external in the current flext setup using single-release. This would imply no use of threads and also statically linking to the .a lib as opposed to the .so. Is this correct? If not what do I need to do to ensure I do so? Sorry but I might have mentioned before I pretty clueless with this gcc stuff.
yep, afaik any -single build should produce a threadless (the official term in Thomas' documentation appears to be "single-threaded") version; at least, the flext build system won't define FLEXT_THREADS for *-single builds. Just make sure you're not defining it yourself ;-)
... 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)
Should -UFLEXT_THREADS be added to my config.txt in the external directory.
UFLAGS += -UFLEXT_THREADS ? Or should I ensure it is no defined. -U = undefine ?
If you're not defining it (e.g. with -DFLEXT_THREADS or with a #define in some source file), then you're ok: it won't be defined by flext build.sh for a *-single build.
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 ;-)
I have edited this file so now the part which did contain the pthread stuff looks like this ############################################## #removed from both: -pthread CFLAGS += -fPIC LDFLAGS += -shared
yep, that's the bit I meant. As I noted yesterday, my fluid~ problems were due to a missing initialization / assumed zero-initialization of the object's memory, which resulted in an attempt to free() a pointer of basically random junk (either unallocated or allocated by a different program or thread or whatever)...
According to the gcc docs:
-pthread Add support for multithreading using the POSIX threads library. This option sets flags for both the preprocessor and linker. It does not affect the thread safety of object code produced by the compiler or that of libraries supplied with it. These are HP-UX specific flags.
... there are -pthread flags listed for other architectures too, and gcc doesn't complain about the flags, but I haven't yet found any docs for the -pthread option on x86, so maybe it doesn't do anything at all here except maybe link to libpthread...
One question are you working from 5.0 release of flext or are you using the head of cvs?
I'm using the head of cvs, and I haven't actually removed the "-pthread" from my build flags here. Of course, I am still getting bizarre crashes & lockups, but not the fluid~-related ones.
marmosets, Bryan
-
Bryan Jurish -
Bryan Jurish -
Conor J Curran