Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Losing signals using sigprocmask #6573

Open
p5pRT opened this issue Jun 19, 2003 · 4 comments
Open

Losing signals using sigprocmask #6573

p5pRT opened this issue Jun 19, 2003 · 4 comments

Comments

@p5pRT
Copy link

p5pRT commented Jun 19, 2003

Migrated from rt.perl.org#22735 (status was 'open')

Searchable as RT22735$

@p5pRT
Copy link
Author

p5pRT commented Jun 19, 2003

From paulb@grover.be.ubizen.com

Created by paul.busse@ubizen.com

To​: perlbug@​perl.org
Subject​: Signals are lost when using sigprocmask
Cc​: paul.busse@​ubizen.com
Reply-To​: paul.busse@​ubizen.com
Message-Id​: <5.8.0_5018_1056010067@​devcpu.be.ubizen.com>

This is a bug report for perl from paul.busse@​ubizen.com,
generated with the help of perlbug 1.34 running under perl v5.8.0.

-----------------------------------------------------------------

#!/usr/bin/perl -w

use POSIX;
use Data​::Dumper;

$SIG{HUP} = sub { print "in HUP handler\n";};
my $blockset = POSIX​::SigSet->new(SIGHUP);
my $set = POSIX​::SigSet->new(SIGHUP);
sigprocmask(SIG_BLOCK, $blockset, $set)
  or $​::ENV-&gt;error("Can't block SIGHUP : $!");
#open FH, "cat|" or die "cat|$!\n";
print "TEST\n";
<>; # Comment
#<FH>;
print "TEST2\n";
#close FH;
sigprocmask(SIG_UNBLOCK, $blockset, $set)
  or $​::ENV-&gt;error("Can't unblock SIGHUP : $!");
print "TEST3\n";

The program as listed above runs as expected​: i.e.
When I sent a SIGHUP to the process while it is waiting for
input, the line "in HUP handler" appears between TEST2 and TEST3.

However if I uncomment the commented lines and comment the line
marked with '#Comment' and I sent a SIGHUP to the perl process
(i.e. not the cat) while the process is waiting for the <FH>
I never see the "in HUP handler" line.
So, apparently the signal gets lost.

Perl Info

Flags:
    category=library
    severity=medium

Site configuration information for perl v5.8.0:

Configured by seceng at Fri May 30 17:54:04 MEST 2003.

Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
  Platform:
    osname=solaris, osvers=2.8, archname=sun4-solaris-thread-multi
    uname='sunos marinabuild 5.8 generic_108528-10 sun4u sparc sunw,ultraax-i2 '
    config_args='-ds -e -Dusethreads -Duseithreads -Dcc=gcc -Dinstallprefix=/usr/local -Dprefix=/usr/local'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-D_REENTRANT -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-O',
    cppflags='-D_REENTRANT -fno-strict-aliasing -I/usr/local/include'
    ccversion='', gccversion='2.95.3 20010315 (release)', gccosandvers='solaris2.8'
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags =' -L/usr/local/lib '
    libpth=/usr/local/lib /usr/lib /usr/ccs/lib
    libs=-lsocket -lnsl -ldl -lm -lrt -lpthread -lc
    perllibs=-lsocket -lnsl -ldl -lm -lrt -lpthread -lc
    libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-fPIC', lddlflags='-G -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.8.0:
    /opt/og3/lib
    blib/lib
    /usr/local/lib/perl5/5.8.0/sun4-solaris-thread-multi
    /usr/local/lib/perl5/5.8.0
    /usr/local/lib/perl5/site_perl/5.8.0/sun4-solaris-thread-multi
    /usr/local/lib/perl5/site_perl/5.8.0
    /usr/local/lib/perl5/site_perl
    .


Environment for perl v5.8.0:
    HOME=/disks/tao/bu1-1/paulb
    LANG=C
    LANGUAGE (unset)
    LD_LIBRARY_PATH=/usr/local/xerces/lib:/usr/local/xalan/lib::/opt/sfw/lib:/usr/local/lib:/var/oracle/OraHome1/lib32:/opt/oracle/lib:
    LOGDIR (unset)
    PATH=/usr/local/xerces/bin:/usr/local/xalan/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/bin:/opt/sfw/bin:/disks/tao/bu1-1/paulb/bin:/opt/oracle/bin:/bin:/usr/bin:/usr/local/bin
    PERL5LIB=/opt/og3/lib:blib/lib
    PERL_BADLANG (unset)
    SHELL=/bin/bash

@p5pRT
Copy link
Author

p5pRT commented May 27, 2013

From @jkeenan

On Thu Jun 19 01​:33​:15 2003, paulb@​grover.be.ubizen.com wrote​:

To​: perlbug@​perl.org
Subject​: Signals are lost when using sigprocmask
Cc​: paul.busse@​ubizen.com
Reply-To​: paul.busse@​ubizen.com
Message-Id​: <5.8.0_5018_1056010067@​devcpu.be.ubizen.com>

This is a bug report for perl from paul.busse@​ubizen.com,
generated with the help of perlbug 1.34 running under perl v5.8.0.

-----------------------------------------------------------------

#!/usr/bin/perl -w

use POSIX;
use Data​::Dumper;

$SIG{HUP} = sub { print "in HUP handler\n";};
my $blockset = POSIX​::SigSet->new(SIGHUP);
my $set = POSIX​::SigSet->new(SIGHUP);
sigprocmask(SIG_BLOCK, $blockset, $set)
or $​::ENV-&gt;error("Can't block SIGHUP : $!");
#open FH, "cat|" or die "cat|$!\n";
print "TEST\n";
<>; # Comment
#<FH>;
print "TEST2\n";
#close FH;
sigprocmask(SIG_UNBLOCK, $blockset, $set)
or $​::ENV-&gt;error("Can't unblock SIGHUP : $!");
print "TEST3\n";

The program as listed above runs as expected​: i.e.
When I sent a SIGHUP to the process while it is waiting for
input, the line "in HUP handler" appears between TEST2 and TEST3.

However if I uncomment the commented lines and comment the line
marked with '#Comment' and I sent a SIGHUP to the perl process
(i.e. not the cat) while the process is waiting for the <FH>
I never see the "in HUP handler" line.
So, apparently the signal gets lost.

List​: Is there someone familiar with sending signals to processes who
could review this older ticket?

Thank you very much.
Jim Keenan

@p5pRT
Copy link
Author

p5pRT commented May 27, 2013

The RT System itself - Status changed from 'new' to 'open'

@p5pRT
Copy link
Author

p5pRT commented Jun 9, 2013

From @Leont

On Thu Jun 19 01​:33​:15 2003, paulb@​grover.be.ubizen.com wrote​:

#!/usr/bin/perl -w

use POSIX;
use Data​::Dumper;

$SIG{HUP} = sub { print "in HUP handler\n";};
my $blockset = POSIX​::SigSet->new(SIGHUP);
my $set = POSIX​::SigSet->new(SIGHUP);
sigprocmask(SIG_BLOCK, $blockset, $set)
or $​::ENV-&gt;error("Can't block SIGHUP : $!");
#open FH, "cat|" or die "cat|$!\n";
print "TEST\n";
<>; # Comment
#<FH>;
print "TEST2\n";
#close FH;
sigprocmask(SIG_UNBLOCK, $blockset, $set)
or $​::ENV-&gt;error("Can't unblock SIGHUP : $!");
print "TEST3\n";

The program as listed above runs as expected​: i.e.
When I sent a SIGHUP to the process while it is waiting for
input, the line "in HUP handler" appears between TEST2 and TEST3.

However if I uncomment the commented lines and comment the line
marked with '#Comment' and I sent a SIGHUP to the perl process
(i.e. not the cat) while the process is waiting for the <FH>
I never see the "in HUP handler" line.
So, apparently the signal gets lost.

To quote POSIX​:

"Some historical implementations of pclose() either block or ignore the
signals SIGINT, SIGQUIT, and SIGHUP while waiting for the child process
to terminate. Since this behavior is not described for the pclose()
function in IEEE Std 1003.1-2001, such implementations are not conforming."

Perl is such an implementation. Setting the signal disposition to ignore
may throw away any pending signals even when they're blocked. This logic
was implemented in perl 3.0 back in 1989.

I pushed a fix that removed this logic entirely to a smoke-me branch.

Leon

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants