OK, I now have a FreeBSD virtual machine that exhibits this problem. Like you Slaven, I see it about 10% of the time.
There's a line
$XSIG{$_}[0] = undef for keys %_XSIG
in the Signals::XSIG::TieSig::CLEAR function. I find that if the very first key returns by 'keys' is 'USR1' or 'USR2', then the test will fail. If the first key is some other signal name, it succeeds (though I didn't try them all).
If I change the test to use '__WARN__' or '__DIE__' as the test signals ($s1 and $s2 in t/02-SIGhash.t), and arrange for '__WARN__' and '__DIE__' to be the first signals in the for loop list, then the test also succeeds.
And if that works, I have no idea why.
On Sat Apr 29 14:56:08 2017, SREZIC wrote:
Show quoted text> A fail report 0.15_03 is attached (current ratio on my smokers: 65
> pass vs. 7 fail).
>
> On 2017-04-28 01:35:59, SREZIC wrote:
> > Unfortunately not, see the attached file.
> >
> > On 2017-04-27 12:21:56, MOB wrote:
> > > Thank you, Slaven. You are really going above and beyond the call
> > > of
> > > duty here.
> > >
> > > Signals-XSIG-0.15_02 has been uploaded, which just might make this
> > > problem go away.
> > >
> > > -- Marty
> > >
> > >
> > >
> > > On Thu Apr 27 02:34:15 2017, SREZIC wrote:
> > > > CPAN Testers is slow these days, so I am attaching a fail report
> > > > with
> > > > the additional diagnostics.
> > > >
> > > > -- Slaven
> > > >
> > > > On 2017-04-26 15:51:20, MOB wrote:
> > > > > Well then I'm sorry I haven't uploaded my additional
> > > > > diagnostics
> > > > > for
> > > > > this issue and we missed this opportunity.
> > > > > Watch for 0.15_01 coming soon.
> > > > >
> > > > > -- Marty
> > > > >
> > > > >
> >
> >