develooper Front page | perl.perl5.porters | Postings from April 2011

Re: Smoke [5.13.11] v5.13.11-190-g5da6b59 FAIL(F) openbsd 4.8 (i386/1 cpu)

Thread Previous | Thread Next
From:
Leon Timmermans
Date:
April 20, 2011 08:06
Subject:
Re: Smoke [5.13.11] v5.13.11-190-g5da6b59 FAIL(F) openbsd 4.8 (i386/1 cpu)
Message ID:
BANLkTine-9uNb4gCoNEVkj__XPKi_1L9OA@mail.gmail.com
On Tue, Apr 12, 2011 at 11:13 PM, Dave Mitchell <davem@iabyn.com> wrote:
> This test has been hanging the test script on openbsd and mirbsd
> since it was added with commit 0c1bf4c7d433bb0ad80bfe5511b1301db32b7b95.
>
> The test in question does:
>
>    require POSIX;
>    my $new = POSIX::SigSet->new(&POSIX::SIGUSR1);
>    POSIX::sigprocmask(&POSIX::SIG_BLOCK, $new);
>
>    my $gotit = 0;
>    $SIG{USR1} = sub { $gotit++ };
>    kill SIGUSR1, $$;
>    is $gotit, 0, 'Haven\'t received third signal yet';
>
>    my $old = POSIX::SigSet->new();
>    POSIX::sigsuspend($old); <=== HANGS HERE
>
> so somehow the signal gets lost rather than just being temporarily blocked.
> Does anyone with *bsd access have any further insights?

Ugh, portable signal handling really does suck balls. I really don't
have the time to look deeply into this right now, but I would suggest
someone to port the test in question to C (should be fairly
straightforward) and try to run it. If that also doesn't work either
it's the OS that's at fault. My experience with OpenBSD and POSIXy
stuff has been to assume that it doesn't work until there's proof of
the opposite :-(. straceing (or whatever OpenBSD uses for that) may
also provide insights on whether the signal really doesn't arrive or
that something else happens.

Leon

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About