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]
