I've managed to answer my own question: In our main application the call to pth_init() is made after the signals are blocked, hence it is missing from the example I gave. Shifting the calls to the correct order solves the problem. I suspect that libraries updated at the same time as the kernel changed whatever it was that had allowed our code to run without problems before. I guess we've just been lucky up to this point :)
- Lee On Mon, 2004-12-20 at 02:55 +0000, Lee Hearne wrote: > I have some software that's been running on Linux (kernel 2.4) systems > for a number of years. On the boxes we've recently upgraded to 2.6 > kernels this same code now fails every time. The problem occurs when we > initially call pth_sigmask() to block all the signals. > > Example code: > > --------------------- > > #include <signal.h> > #include <errno.h> > #include <pth.h> > > int main (int argc, char *argv[]) > { > using namespace std; > > sigset_t ss, old_ss; > > cout << "Blocking signals..." << endl; > > sigfillset(&ss); > int rc = sigprocmask(SIG_SETMASK, &ss, 0); > //pth_sigmask(SIG_SETMASK, &ss, 0); > > cout << "Signals blocked: rc " << rc << " errno: " << errno << " > - " > << strerror(errno) << endl; > } > > ---------------- > > Our libpth was configured with --enable-syscall-soft, so the above fails > as is. > > GDB Output: > > (gdb) r > Starting program: /home/lhearne/work/tmp/signals > Blocking signals... > > Program received signal SIGSEGV, Segmentation fault. > 0x00138d57 in sigprocmask () from /lib/tls/libc.so.6 > (gdb) backtrace > #0 0x00138d57 in sigprocmask () from /lib/tls/libc.so.6 > #1 0x0097325a in pth_sigmask () from /usr/local/lib/libpth.so.20 > #2 0x08048a88 in main (argc=1, argv=0xfeff17d4) at signals.cpp:16 > > If the pth header is excluded from above code the standard system call > is made and the program runs to completion. > > Has anyone else come across this problem, or can anyone get the example > to run on a 2.6 based system? > > For pth_sigmask the pth manual states "...alternatively you can also > directly call sigprocmask(2), but for consistency reasons you should use > this function pth_sigmask(3)." Is there anything lost by just calling > sigprocmask? Ideally I like to find a pth solution that is compatible > with both kernels. :-) > > Detail of the 2.6 system I've tested this on: > > Fedora Core 3 > > $ uname -rv > 2.6.9-1.681_FC3 #1 Thu Nov 18 15:10:10 EST 2004 > $ pth-config --version > GNU Pth 2.0.3 (03-Dec-2004) > $ gcc --version > gcc (GCC) 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) > $ rpm --query glibc > glibc-2.3.3-74 > > > SuSE Enterprise > > $ uname -rv > 2.6.5-7.111.5-smp #1 SMP Wed Nov 17 11:08:17 UTC 2004 > $ pth-config --version > GNU Pth 2.0.2 (12-Sep-2004) > $ gcc --version > gcc (GCC) 3.3.3 (SuSE Linux) > $ rpm --query glibc > glibc-2.3.3-98.31 > > > Thanks for reading, > > - Lee Hearne > > > ______________________________________________________________________ > GNU Portable Threads (Pth) http://www.gnu.org/software/pth/ > Development Site http://www.ossp.org/pkg/lib/pth/ > Distribution Files ftp://ftp.gnu.org/gnu/pth/ > Distribution Snapshots ftp://ftp.ossp.org/pkg/lib/pth/ > User Support Mailing List [EMAIL PROTECTED] > Automated List Manager (Majordomo) [EMAIL PROTECTED] > ______________________________________________________________________ GNU Portable Threads (Pth) http://www.gnu.org/software/pth/ Development Site http://www.ossp.org/pkg/lib/pth/ Distribution Files ftp://ftp.gnu.org/gnu/pth/ Distribution Snapshots ftp://ftp.ossp.org/pkg/lib/pth/ User Support Mailing List [EMAIL PROTECTED] Automated List Manager (Majordomo) [EMAIL PROTECTED]