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');
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] |
| [reply] |
Hi there I was referred to this post which states this is actually a bug in PERL 5.12
https://rt.perl.org/Public/Bug/Display.html?id=76138
That seems to match your problem. Consider upgrading to a newer version of RHEL that uses a newer version of perl, or ditch the perl provided by RedHat and compile your own perl. (RH perl should be in /usr/bin/perl, so compile your own perl to /usr/local/bin/perl and change the #! line in your scripts.) You may also try a forced installation of a newer perl version on the current RHEL version.
And please note: Perl is the language, perl is the implementation, and PERL is just wrong.
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] |