Skip Menu |

This queue is for tickets about the Sys-SigAction CPAN distribution.

Report information
The Basics
Id: 105091
Status: resolved
Priority: 0/
Queue: Sys-SigAction

People
Owner: Nobody in particular
Requestors: ppisar [...] redhat.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 0.21
Fixed in: (no value)



Subject: t/nested.t segfaults on ARM
t/nested.t tests segfaults for me on ARM platform with glibc and Linux: # perl -Ilib t/nested.t 1..4 level 3 level 2 Segmentation fault
From: ppisar [...] redhat.com
Dne Po 08.čen.2015 09:20:10, ppisar napsal(a): Show quoted text
> t/nested.t tests segfaults for me on ARM platform with glibc and Linux: > > # perl -Ilib t/nested.t > 1..4 > level 3 > level 2 > Segmentation fault
I forgot to write down versions: perl-5.20.2 glibc-2.20 and 2.21.90 Linux-3.2.27 and something newer I cannot identify now.
On Mon Jun 08 09:23:11 2015, ppisar wrote: Show quoted text
> Dne Po 08.čen.2015 09:20:10, ppisar napsal(a):
> > t/nested.t tests segfaults for me on ARM platform with glibc and Linux: > > > > # perl -Ilib t/nested.t > > 1..4 > > level 3 > > level 2 > > Segmentation fault
> > I forgot to write down versions: > > perl-5.20.2 > glibc-2.20 and 2.21.90 > Linux-3.2.27 and something newer I cannot identify now.
Does this still seg fault on current versions of ARM
Subject: Re: [rt.cpan.org #105091] t/nested.t segfaults on ARM
Date: Mon, 25 Jul 2016 10:58:23 +0200
To: Lincoln A Baxter via RT <bug-Sys-SigAction [...] rt.cpan.org>
From: Petr Pisar <ppisar [...] redhat.com>
On Sun, Jul 24, 2016 at 06:01:22PM -0400, Lincoln A Baxter via RT wrote: Show quoted text
> Does this still seg fault on current versions of ARM
Yes. perl-5.24.0, glibc-2.23.90. -- Petr
Download signature.asc
application/pgp-signature 213b

Message body not shown because it is not plain text.

On Mon Jul 25 04:58:36 2016, ppisar wrote: Show quoted text
> On Sun, Jul 24, 2016 at 06:01:22PM -0400, Lincoln A Baxter via RT wrote:
> > Does this still seg fault on current versions of ARM
> > Yes. perl-5.24.0, glibc-2.23.90. > > -- Petr
Hi Petr, Can you show me the output of: perl -MConfig -e 'print $Config{archname} ."\n" ;' Also I have attached a rewritten nested.t that allows one to control both the depth of nesting and the number of iterations. Can you run this first without arguments (as in): perl -Ilib t/nested.t On your platform (if I guessed the archname string right) is will default to a depth of 2 and 2 iterations. Please show me the out if it segfaults. Then can you run it with different depths set (as in): perl -Ilib t/nested.t 5 1 #depth of 5, 1 iteration perl -Ilib t/nested.t 5 1 #depth of 4, 1 iteration perl -Ilib t/nested.t 5 1 #depth of 3, 1 iteration perl -Ilib t/nested.t 5 1 #depth of 1, 1 iteration Please show me the output of each test that segfaults, and know which tests succeed. I want to understand better what the limits are, so I can set the defaults in this rewritten test to appropriate values. Because this works fine on all the POSIX (unix) platforms the smoke testers have tested on, the I suspect this is a problem with the underlying signal handling in perl on ARM platforms. Apparently there are no smoke testers using ARM. So, if you want this port of perl fixed, you'll want to get a stack trace from the core file resulting from the segfault and file a bug against this perl port. thanks, Lincoln
Subject: nested.t
# Before `make install' is performed this script should be runnable with # `make test'. After `make install' it should work as `perl filename.t' ######################### # change 'tests => 1' to 'tests => last_test_to_print'; use Test::More; # tests => 5; #BEGIN { use_ok('Sys::SigAction') }; use Sys::SigAction; ######################### # Insert your test code below, the Test::More module is use()ed here so read # its man page ( perldoc Test::More ) for help writing this test script. use strict; #use warnings; use Carp qw( carp cluck croak confess ); use Data::Dumper; use Sys::SigAction qw( set_sig_handler ); use POSIX ':signal_h' ; use Config; #plan is a follows: # # A test that sets signal handlers in nested blocks, and tests that # at each level of nesting, the signal handler at the next level up # is still valid (for the same signal). The idea is that the scope of # the block prevents the next level up signal handle from being overwritten. # # NOTE: smoke testers on ARM find that this test fails with a perl segfault # two levels up from the deepest level... :-( #global... should be good at the end... my @levels = ( ); my $depth = $ARGV[0]; my $repetitions = $ARGV[1]; $repetitions = 2 if not defined $repetitions; my $arch = $Config{'archname'} ; print "archname = $arch}\n" ; if ( $Config{'archname'} =~ m/arm/i ) { if ( not defined $depth ) { print qq( NOTE: 'arm' found in \$Config{'archname'} Bug # was filed against Sys::SigAction noting that this test causes a perl segfault (apparently if the depth of nested invocations is greater than 2). Forcing depth to $depth on this platform. depth=$depth If this test is run manually, you can explicitly set both the depth of nesting and the number of repetitions of this test. perl -Ilib t/nested.t 5 2 #depth=5 repetitions=2 Because this works fine on all the POSIX (unix) platforms the smoke testers have tested on, the author suspect this is a problem with the underlying signal handling in perl on ARM platforms. Apparently there are no smoke testers using ARM. So, if you want this port of perl fixed, you'll want to get a stack trace from the core file resulting from the segfault and file a bug against this perl port. ); $depth = 2 } } else { $depth = 5 if not defined $depth; $repetitions = 2 if not defined $repetitions; } plan tests => $depth*$repetitions; #recurses until $level > $depth sub do_level { my ( $level ) = @_; return if $level > $depth; print "entered do_level( $level )\n" ; do_level( $level+1 ); eval { my $ctx = set_sig_handler( SIGALRM ,sub { print "in ALRM handler level $level\n"; $levels[$level-1] = $level; } ); kill ALRM => $$; }; if ($@) { warn "handler died at level $level: $@\n"; } } sub do_test { my ( $p ) = ( @_ ); my $i = 0; print "depth = $depth\n" ; print "initializing levels array to all 0 for every depth\n" ; while ( $i < $depth ) { push( @levels, 0 ); $i++; } do_level( 1 ); $i = 0; for ( $i = $depth-1; $i > -1; $i-- ) { ok( $levels[$i] ,"pass $p: \$levels[$i] was set by the signal handler to $levels[$i]" ); print "\$levels[$i] = " .$levels[$i] . "\n" ; } } my $pass = 1; while ( $pass <= $repetitions ) { print "starting pass $pass\n" ; do_test( $pass ); $pass++; } exit;
On Sat Aug 20 11:01:19 2016, LBAXTER wrote: Show quoted text
> perl -Ilib t/nested.t 5 1 #depth of 5, 1 iteration > perl -Ilib t/nested.t 5 1 #depth of 4, 1 iteration > perl -Ilib t/nested.t 5 1 #depth of 3, 1 iteration > perl -Ilib t/nested.t 5 1 #depth of 1, 1 iteration >
This should have been: perl -Ilib t/nested.t 5 1 #depth of 5, 1 iteration perl -Ilib t/nested.t 4 1 #depth of 4, 1 iteration perl -Ilib t/nested.t 3 1 #depth of 3, 1 iteration perl -Ilib t/nested.t 1 1 #depth of 1, 1 iteration
Subject: Re: [rt.cpan.org #105091] t/nested.t segfaults on ARM
Date: Wed, 31 Aug 2016 09:53:32 +0200
To: Lincoln A Baxter via RT <bug-Sys-SigAction [...] rt.cpan.org>
From: Petr Pisar <ppisar [...] redhat.com>
On Sat, Aug 20, 2016 at 11:01:19AM -0400, Lincoln A Baxter via RT wrote: Show quoted text
> Can you show me the output of: > > perl -MConfig -e 'print $Config{archname} ."\n" ;' >
armv6j-linux I have now Linux-4.4.11, gcc-5.4.0, glibc-2.22, perl-5.22.2 and Sys-SigAction-0.22. The t/nested.t from Sys-SigAction-0.22 still segfaults. Show quoted text
> Also I have attached a rewritten nested.t that allows one to > control both the depth of nesting and the number of iterations. > Can you run this first without arguments (as in): > > perl -Ilib t/nested.t > > On your platform (if I guessed the archname string right) is will default to > a depth of 2 and 2 iterations. Please show me the out if it segfaults. > > Then can you run it with different depths set (as in): > > perl -Ilib t/nested.t 5 1 #depth of 5, 1 iteration > perl -Ilib t/nested.t 5 1 #depth of 4, 1 iteration > perl -Ilib t/nested.t 5 1 #depth of 3, 1 iteration > perl -Ilib t/nested.t 5 1 #depth of 1, 1 iteration >
None of them (5 1, 4 1 etc.) segfaults with the new t/nested.t. I tried different depths and iterations. Show quoted text
> Because this works fine on all the POSIX (unix) platforms the smoke testers > have tested on, the I suspect this is a problem with the underlying signal > handling in perl on ARM platforms.
I also suspect a bug in the perl. Show quoted text
> So, if you want this port of perl fixed, you'll want to get > a stack trace from the core file resulting from the segfault and file a bug > against this perl port. >
The stack trace is unusable because after the crash, the debuger reports the last two frames are identical so the stack is corrupted. -- Petr
Thanks Petr!!! On Wed Aug 31 03:54:04 2016, ppisar wrote: Show quoted text
> On Sat, Aug 20, 2016 at 11:01:19AM -0400, Lincoln A Baxter via RT > wrote:
> > Can you show me the output of: > > > > perl -MConfig -e 'print $Config{archname} ."\n" ;' > >
> armv6j-linux > > I have now Linux-4.4.11, gcc-5.4.0, glibc-2.22, perl-5.22.2 and > Sys-SigAction-0.22. The t/nested.t from Sys-SigAction-0.22 still > segfaults. >
> > Also I have attached a rewritten nested.t that allows one to > > control both the depth of nesting and the number of iterations. > > Can you run this first without arguments (as in): > > > > perl -Ilib t/nested.t > > > > On your platform (if I guessed the archname string right) is will > > default to > > a depth of 2 and 2 iterations. Please show me the out if it > > segfaults. > > > > Then can you run it with different depths set (as in): > > > > perl -Ilib t/nested.t 5 1 #depth of 5, 1 iteration > > perl -Ilib t/nested.t 5 1 #depth of 4, 1 iteration > > perl -Ilib t/nested.t 5 1 #depth of 3, 1 iteration > > perl -Ilib t/nested.t 5 1 #depth of 1, 1 iteration > >
> None of them (5 1, 4 1 etc.) segfaults with the new t/nested.t. I > tried > different depths and iterations.
Wow... The main difference between the new nested.t and the old one, is that the testing in the new one is performed recursively in a do_test() routine, where as in the original test, the nesting of signals was "inline." I wonder if the recursive call stack is providing enough isolation of whatever is causing perl to crap the bed, so that it is no longer happening. I'm thinking that the original test was pretty contrived... how likely is it, that someone would do what is in the that test. I could easily see one doing it serially at the same level of call, and I can see one doing what the new test does (at differently levels of the call stack). Now I'm thinking, I should just replace the old test with the new, and not worry about it. The original test might be so contrived a test that nobody is doing it, which is why the arm5 and now arm6 perl port remains broken this way. This tempts me to remove the trap of arm5tejl and see if the testers find a problem with the new test. Show quoted text
> > So, if you want this port of perl fixed, you'll want to get > > a stack trace from the core file resulting from the segfault and file > > a bug > > against this perl port. > >
> The stack trace is unusable because after the crash, the debuger > reports the > last two frames are identical so the stack is corrupted.
*sigh* I think this confirms my supposition above that the new recursive nested.t is not getting a segfault because of stack isolation. I guess I now know how I could built a test of this that could be submitted to the perl porter(s) for arm... I would just have insert inline the POSIX.pm code that sys-sigaction implements. Given how twisted the original test code is, I'm not sure it is worth it. Though I suppose I could post a query on the the appropriate porters forum and see it there is interest in fixing it. Thanks for your help. I'll probably release a new version of this with the new nested.t and close this bug. I've some other minor changes I want to make, that I'll probably roll into a new version. The "kwalitee" folk are complaining about that fact that the module doesn't "use warnings" It is in the code but commented out because warnings was only supported in perl 5.006 and later, and I had originally supported this module on perl 5.005. I think I'll just desupport that now. (That was 12 years ago). Lincoln
I never got around to closing this. I changed that way nested.t was working. See most recent message in the history. Lincoln