in reply to Re^4: SIG{CHLD} altered by require statement on Perl 5.12.1
in thread SIG{CHLD} altered by require statement on Perl 5.12.1

I had to modify the code you recommended I run because it was giving me the following error:

Invalid version format (non-numeric data) at perlmonkII.pl line 7, nea
+r "package SpyHash "
syntax error at perlmonkII.pl line 9, near "package SpyHash {

[download]

Yepp, sorry, that's v5.14 syntax.

Then I ran this code on perl v.12.5 and I got

Assign to key CHLD at perlmonkII.pl line 34

So, it seems that Net::DNS does not modify $SIG{CHLD}. Or it does modify it so far behind the scenes that tie magic does not catch it.

Are you sure that your code does not mess with $SIG{CHLD}? Search all your sources for CHLD or $SIG.

Let's assume your code is clean. I added some calls to Data::Dumper to that code to verify the value of $SIG{CHLD}. Could you try that script? Comment out the tie %SIG,'SpyHash'; line and run again, so that we can see if tie has any effects.

#!/usr/bin/perl

use v5.12;
use strict;
use warnings;
use Data::Dumper;

package SpyHash;

use Tie::Hash; # for Tie::StdHash
use Carp qw( carp );

our @ISA=qw( Tie::StdHash );

sub STORE{
        my ($self,$key,$value)=@_;
        $key=~/^CH?LD$/ and carp "Assign to key $key";
        return $self->SUPER::STORE($key,$value);
    }

sub DELETE
    {
        my ($self,$key)=@_;
        $key=~/^CH?LD$/ and carp "Delete key $key";
        return $self->SUPER::DELETE($key);
    }

   1;


package main;

sub info
{
        my $where=shift;
        print $where,": ",Dumper($SIG{'CHLD'}),"\n";
}

info('start');
tie %SIG,'SpyHash';
info('after tie');
$SIG{'CHLD'}=sub { 'just a dummy' }; # this line should be reported
info('after set handler');
require Net::DNS; # Any module messing with $SIG{'CHLD'} should be rep
+orted from here
info('after require');
Net::DNS->import(); # ... or here
info('after import');
# For some extra paranoia, pretend to do some work with Net::DNS:
my $dns=Net::DNS::Resolver->new();
info('after creating instance');
my $reply=$dns->search('localhost');
info('after resolving localhost');
$reply=$dns->search('no.such.host.anywhere.invalid.');
info('after resolving junk');

[download]

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Replies are listed 'Best First'.
Re^6: SIG{CHLD} altered by require statement on Perl 5.12.1
by sdingare (Initiate) on Apr 17, 2015 at 19:40 UTC
    Here's the output of your latest script: 
    
start: $VAR1 = undef;

after tie: $VAR1 = undef;

Assign to key CHLD at perlmonkIII.pl line 42
after set handler: $VAR1 = sub { "DUMMY" };

after require: $VAR1 = sub { "DUMMY" };

after import: $VAR1 = sub { "DUMMY" };

after creating instance: $VAR1 = sub { "DUMMY" };

after resolving localhost: $VAR1 = sub { "DUMMY" };

after resolving junk: $VAR1 = sub { "DUMMY" };

    [download]
    The sources I posted in the first post were the entirety of the code that led to the oddity documented there. Could the tie itself be changing the behaviour seen there?
[reply]
[d/l]
      For example, if I comment out this single line from your latest script: tie %SIG,'SpyHash'; then my output becomes: 
       
start: $VAR1 = undef;

after tie: $VAR1 = undef;

after set handler: $VAR1 = sub { "DUMMY" };

after require: $VAR1 = undef;

after import: $VAR1 = undef;

after creating instance: $VAR1 = undef;

after resolving localhost: $VAR1 = undef;

after resolving junk: $VAR1 = undef;

      [download]
[reply]
[d/l]
[select]

        Hmm, it seems that tie hides / heals the problem instead of showing where $SIG{CHLD} is reset. Whatever changes $SIG{CHLD} does not use the "normal" way of storing values in a hash.

        What might have happened here: The %SIG hash has some "magic" attached (see mg_vtable.h and mg.c in the perl sources), using tie changes that "magic" to the usual tie magic, and so the symbol %SIG no longer reflects the inner workings of perl (and the operating system). The "real" $SIG{CHLD} (the inner workings) was probably changed in both runs. And because the visible %SIG was not changed in the tied version of the test script, Net::DNS or code loaded by Net::DNS must have changed the "inner workings".

        This should be visible when you untie %SIG after require. Change ...

        info('after require');

        ... to ...

        info('after require - still tied');
untie %SIG;
info('after require - untied');

        [download]

        How could that happen?

        • Some pure perl code loaded by Net::DNS explicitly tests that %SIG is tied, somehow accesses the untied %SIG, and makes sure that the remaining parts of the code still sees the tied %SIG. Unlikely.
        • Some XS code loaded by Net::DNS manipulates signals by using perl's C API, bypassing %SIG.
        • You stepped on a bug in perl, triggered by Net::DNS. Quite unlikely.

        Now what?

        • Find and report the problem. Wasted time, both Perl 5.12 and Net::DNS 0.66 are OLD.
        • Upgrade to more recent versions. Current versions are Perl 5.20.2 and Net::DNS 0.83.
        • If some stupid policy requires that those old versions are to be used, try to change that policy.
        • If you can't change the policy, be prepared for several hours with the perl debugger. Use the test script without tie and try to find out where $SIG{CHLD} becomes undef.
        • If you don't like the debugger, dump sort keys %INC before and after require Net::DNS; and search all of the source code of all modules loaded by Net::DNS for anything related to signals. Very likely, the problem is in C or XS code.

        Another possibility: RHEL 5.11 was released in 2014, but it is based on code from 2007. Perl 5.12.5 was released in November 2012, so the first RHEL 5.x version that could containing that Perl version was 5.9 released in January 2013. Net::DNS 0.66 was released before January 2012, so it may have been part of RHEL 5.x since RHEL 5.8 released in February 2012. In January 2013, when RHEL was released, Net::DNS should have been updated to 0.69 to 0.72, all released in December 2012. What if someone at Redhat simply forgot to update Net::DNS and used the old version compiled for the older Perl version from RHEL 5.8?

        A last idea: In Re^2: SIG{CHLD} altered by require statement on Perl 5.12.1, you show that both perl 5.8.8 and perl 5.12.5 use identical versions of Net::DNS. Did you mix both versions of Perl so that Perl 5.12.5 accidentally uses Net::DNS for perl 5.8.8? Compare the output of perl -e 'print join("\n",@INC)' for both perl versions. There should be no directory shared by both perl versions.

        Alexander

        --
        Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom