>> Is there any way to get a better idea of why the SIGABRT is being raised?
> Sure.. edit the generated Makefile and add "-g" to CFLAGS so that
> debugging information is preserved.
I think what you want is to run configure with --enable-debug ... this
not only turns on copmilation w/ -g but also turns off optimization
generates some more compiler options w/ gcc (-gdb3) as well. It also
causes Pth to spew lots of information about what it is doing,
particularly the scheduler. This might give a clue as to what is
happening. Maybe it also enables more internal checks, I don't know,
but if so it could trap the error sooner and with more information.
I also found it useful to spawn threads w/ a name associated
pth_attr_set(a, PTH_ATTR_NAME, "foo") which is then echoed in the
debug output.
One thing about --enable-debug is that there doesn't seem to be a way
to turn the message spew on and off. I ended up hacking pth_debug.c
and putting in pth_debug.c:
/* pth_debug.c */
int pth_debug_enabled = 0;
/* pth_debug() */
if ( ! pth_debug_enabled )
return;
... then in my own code I turn on pth_debug_enabled as needed
when I have a threading issue.
good luck!
---
John Hinsdale, President, Alma Mater Software, Inc.
[EMAIL PROTECTED] | http://www.alma.com/staff/hin | +1 914 631 4690
______________________________________________________________________
GNU Portable Threads (Pth) http://www.gnu.org/software/pth/
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager (Majordomo) [EMAIL PROTECTED]
