Bug #54825 for Inline: Warnings During Build

Sat Feb 20 14:01:05 2010 JAWNSY [...] cpan.org - Ticket created

Subject:

Warnings During Build

Hi there, While trying to build the latest version of Inline for Debian (where it is packaged as libinline-perl), I encountered several warnings and suspicious diagnostic output during testing. As far as I can tell from the toolchain output, there were no dependencies missing during build. What follows is the test output: dh_auto_test make[1]: Entering directory `/build/jon-libinline-perl_0.46-1-i386-lJq_CL/libinline-perl-0.46' make[2]: Entering directory `/build/jon-libinline-perl_0.46-1-i386-lJq_CL/libinline-perl-0.46/C' make[2]: Leaving directory `/build/jon-libinline-perl_0.46-1-i386-lJq_CL/libinline-perl-0.46/C' PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/00init.t .... ok t/01usages.t .. ok t/02config.t .. ok t/03errors.t .. ok t/04create.t .. ok t/05files.t ... skipped: (no reason given) All tests successful. Files=6, Tests=14, 11 wallclock secs ( 0.04 usr 0.02 sys + 0.50 cusr 0.10 csys = 0.66 CPU) Result: PASS make[2]: Entering directory `/build/jon-libinline-perl_0.46-1-i386-lJq_CL/libinline-perl-0.46/C' PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, '../blib/lib', '../blib/arch')" t/*.t t/00init.t ........... ok t/01syntax.t ......... ok t/02config.t ......... ok t/03typemap.t ........ ok t/04perlapi.t ........ ok t/05xsmode.t ......... ok Subroutine Inline::C::get_parser redefined at ../blib/lib/Inline.pm line 312 (#1) (W redefine) You redefined a subroutine. To suppress this warning, say { no warnings 'redefine'; eval "sub name { ... }"; } t/06parseregexp.t .... ok Subroutine Inline::C::get_parser redefined at ../blib/lib/Inline.pm line 312 (#1) (W redefine) You redefined a subroutine. To suppress this warning, say { no warnings 'redefine'; eval "sub name { ... }"; } t/07typemap_multi.t .. ok In Inline::env_untaint() : Blindly untainting tainted fields in %ENV. In Inline::env_untaint() : Blindly untainting tainted fields in %ENV. In Inline::obj_untaint() : Blindly untainting tainted fields in Inline object. In Inline::env_untaint() : Blindly untainting tainted fields in %ENV. In Inline::env_untaint() : Blindly untainting tainted fields in %ENV. In Inline::obj_untaint() : Blindly untainting tainted fields in Inline object. In Inline::env_untaint() : Blindly untainting tainted fields in %ENV. In Inline::env_untaint() : Blindly untainting tainted fields in %ENV. In Inline::obj_untaint() : Blindly untainting tainted fields in Inline object. In Inline::env_untaint() : Blindly untainting tainted fields in %ENV. In Inline::env_untaint() : Blindly untainting tainted fields in %ENV. In Inline::obj_untaint() : Blindly untainting tainted fields in Inline object. t/08taint.t .......... ok All tests successful. Files=9, Tests=21, 13 wallclock secs ( 0.02 usr 0.02 sys + 9.50 cusr 3.24 csys = 12.78 CPU) Result: PASS This regression appears to have been introduced in version 0.46; rebuilding 0.45 with the most recent perl and other dependencies yields the following test output: dh_auto_test make[1]: Entering directory `/build/jon-libinline-perl_0.45-1-i386-dvYTxJ/libinline-perl-0.45' make[2]: Entering directory `/build/jon-libinline-perl_0.45-1-i386-dvYTxJ/libinline-perl-0.45/C' make[2]: Leaving directory `/build/jon-libinline-perl_0.45-1-i386-dvYTxJ/libinline-perl-0.45/C' PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/00init.t .... ok t/01usages.t .. ok t/02config.t .. ok t/03errors.t .. ok t/04create.t .. ok t/05files.t ... skipped: (no reason given) All tests successful. Files=6, Tests=14, 10 wallclock secs ( 0.04 usr 0.02 sys + 0.56 cusr 0.06 csys = 0.68 CPU) Result: PASS make[2]: Entering directory `/build/jon-libinline-perl_0.45-1-i386-dvYTxJ/libinline-perl-0.45/C' PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, '../blib/lib', '../blib/arch')" t/*.t t/00init.t ........... ok t/01syntax.t ......... ok t/02config.t ......... ok t/03typemap.t ........ ok t/04perlapi.t ........ ok t/05xsmode.t ......... ok t/06parseregexp.t .... ok t/07typemap_multi.t .. ok All tests successful. Files=8, Tests=16, 10 wallclock secs ( 0.04 usr 0.02 sys + 7.00 cusr 2.48 csys = 9.54 CPU) Result: PASS

Sat Feb 20 20:29:45 2010 sisyphus [...] cpan.org - Correspondence added

RT-Send-CC:

inline [...] perl.org

On Sat Feb 20 14:01:05 2010, JAWNSY wrote: Show quoted text

> Hi there, > > While trying to build the latest version of Inline for Debian (where

it Show quoted text

> is packaged as libinline-perl), I encountered several warnings and > suspicious diagnostic output during testing. As far as I can tell from > the toolchain output, there were no dependencies missing during build. > > What follows is the test output: > > dh_auto_test > make[1]: Entering directory > `/build/jon-libinline-perl_0.46-1-i386-lJq_CL/libinline-perl-0.46' > make[2]: Entering directory > `/build/jon-libinline-perl_0.46-1-i386-lJq_CL/libinline-perl-0.46/C' > make[2]: Leaving directory > `/build/jon-libinline-perl_0.46-1-i386-lJq_CL/libinline-perl-0.46/C' > PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" > "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t > t/00init.t .... ok > t/01usages.t .. ok > t/02config.t .. ok > t/03errors.t .. ok > t/04create.t .. ok > t/05files.t ... skipped: (no reason given) > All tests successful. > Files=6, Tests=14, 11 wallclock secs ( 0.04 usr 0.02 sys + 0.50

cusr Show quoted text

> 0.10 csys = 0.66 CPU) > Result: PASS > make[2]: Entering directory > `/build/jon-libinline-perl_0.46-1-i386-lJq_CL/libinline-perl-0.46/C' > PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" > "test_harness(0, '../blib/lib', '../blib/arch')" t/*.t > t/00init.t ........... ok > t/01syntax.t ......... ok > t/02config.t ......... ok > t/03typemap.t ........ ok > t/04perlapi.t ........ ok > t/05xsmode.t ......... ok > Subroutine Inline::C::get_parser redefined at ../blib/lib/Inline.pm

line Show quoted text

> 312 (#1) > (W redefine) You redefined a subroutine. To suppress this

warning, say Show quoted text

> > { > no warnings 'redefine'; > eval "sub name { ... }"; > } > > t/06parseregexp.t .... ok > Subroutine Inline::C::get_parser redefined at ../blib/lib/Inline.pm

line Show quoted text

> 312 (#1) > (W redefine) You redefined a subroutine. To suppress this

warning, say Show quoted text

> > { > no warnings 'redefine'; > eval "sub name { ... }"; > } > > t/07typemap_multi.t .. ok > In Inline::env_untaint() : Blindly untainting tainted fields in %ENV. > In Inline::env_untaint() : Blindly untainting tainted fields in %ENV. > In Inline::obj_untaint() : Blindly untainting tainted fields in Inline > object. > In Inline::env_untaint() : Blindly untainting tainted fields in %ENV. > In Inline::env_untaint() : Blindly untainting tainted fields in %ENV. > In Inline::obj_untaint() : Blindly untainting tainted fields in Inline > object. > In Inline::env_untaint() : Blindly untainting tainted fields in %ENV. > In Inline::env_untaint() : Blindly untainting tainted fields in %ENV. > In Inline::obj_untaint() : Blindly untainting tainted fields in Inline > object. > In Inline::env_untaint() : Blindly untainting tainted fields in %ENV. > In Inline::env_untaint() : Blindly untainting tainted fields in %ENV. > In Inline::obj_untaint() : Blindly untainting tainted fields in Inline > object. > t/08taint.t .......... ok > All tests successful. > Files=9, Tests=21, 13 wallclock secs ( 0.02 usr 0.02 sys + 9.50

cusr Show quoted text

> 3.24 csys = 12.78 CPU) > Result: PASS > > This regression appears to have been introduced in version 0.46; > rebuilding 0.45 with the most recent perl and other dependencies

yields Show quoted text

> the following test output: > > dh_auto_test > make[1]: Entering directory > `/build/jon-libinline-perl_0.45-1-i386-dvYTxJ/libinline-perl-0.45' > make[2]: Entering directory > `/build/jon-libinline-perl_0.45-1-i386-dvYTxJ/libinline-perl-0.45/C' > make[2]: Leaving directory > `/build/jon-libinline-perl_0.45-1-i386-dvYTxJ/libinline-perl-0.45/C' > PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" > "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t > t/00init.t .... ok > t/01usages.t .. ok > t/02config.t .. ok > t/03errors.t .. ok > t/04create.t .. ok > t/05files.t ... skipped: (no reason given) > All tests successful. > Files=6, Tests=14, 10 wallclock secs ( 0.04 usr 0.02 sys + 0.56

cusr Show quoted text

> 0.06 csys = 0.68 CPU) > Result: PASS > make[2]: Entering directory > `/build/jon-libinline-perl_0.45-1-i386-dvYTxJ/libinline-perl-0.45/C' > PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" > "test_harness(0, '../blib/lib', '../blib/arch')" t/*.t > t/00init.t ........... ok > t/01syntax.t ......... ok > t/02config.t ......... ok > t/03typemap.t ........ ok > t/04perlapi.t ........ ok > t/05xsmode.t ......... ok > t/06parseregexp.t .... ok > t/07typemap_multi.t .. ok > All tests successful. > Files=8, Tests=16, 10 wallclock secs ( 0.04 usr 0.02 sys + 7.00

cusr Show quoted text

> 2.48 csys = 9.54 CPU) > Result: PASS

The "suspicious diagnostic output" is just the standard "use diagnostics;" ouptut - assuming I've correctly identified the output you're referring to :-) The redefinition warnings come about as a result of "fixing" #49669: https://rt.cpan.org/Public/Bug/Display.html?id=49669 Basically, I think we could silence the warnings in one of 2 ways: 1) Fix #49669 in such a way that get_parser() does not get redefined; 2) Take the advice of the diagnostics message and wrap the offending code in a "no_warnings 'redefine';" block. Solution 1) would be preferable - patches welcome. In the meantime I would prefer to keep the warning (which happens only at build time, btw) in place. I can't be entirely sure that this "fix" does not break something else - and if it *does* break something else, then the warning possibly serves as a significant aid in tracking down the cause of the problem. I would be really pissed off if I spent hours tracking down a bug that could have been solved in minutes if not for a certain piece of code having been placed in a "no warnings 'redefine';" block. The "no warnings" approach would also mean that Inline would have to "require 5.006;" rather than "require 5.005;" as is currently the case. (Requiring 5.006 wouldn't bother me in the slightest - so long as Ingy is happy with that. Faik, there might already be code in place that prevents Inline building on 5.005.) The "untaint" warnings come about as a result of fixing #13084: https://rt.cpan.org/Public/Bug/Display.html?id=13084 As the warnings indicate, untainting involves "blindly untainting" %ENV and Inline objects. It would be irresponsible, imo, to do that without issuing those warnings (which will be seen whenever the script is run). There is an option for a user to silence them by setting the config option NO_UNTAINT_WARN. (I'm now actually wondering whether I should have provided that option.) Cheers, Rob

Sat Feb 20 20:29:52 2010 The RT System itself - Status changed from 'new' to 'open'

Sat Feb 20 21:03:44 2010 JAWNSY [...] cpan.org - Correspondence added

Rob, Thanks for the quick response. I consider this to be an annoying bug, but not a showstopper. I'm happy to know that you are aware of these warnings and are investigating possible options to fix them. The options you've come up with would seem to match ideas I'd have as well, and I understand they sort of leave you between a rock and a hard place. Thanks for your great work on this. I will try to get the current version uploaded to Debian, and hopefully you are able to fix these test issues for a future release. I appreciate your detailed explanation of the situation. Thanks for uploading your module to CPAN and working on such a neat and useful module :)

Thu Jan 20 21:42:52 2011 sisyphus [...] cpan.org - Correspondence added

RT-Send-CC:

inline [...] perl.org, JAWNSY [...] cpan.org

Hi, The "Subroutine Inline::C::get_parser redefined..." warnings and associated diagnostic comments have gone, but the "Blindly untaininting ..." warnings are still there (as I believe it's important that Inline tells us that it's doing these things). During the running of the test suite these warnings are, however, now pre-announced with the message: Expect a number of "Blindly untainting ..." warnings - these are intended. So I'm now closing this ticket. But check out Inline-0.47 (uploaded to CPAN today) and see what you think. If you require further action on this (or would simply prefer that the ticket remain open), please feel free to re-open it. (I think you can do that by simply updating this ticket ... not sure :-) Cheers, Rob

Thu Jan 20 21:42:54 2011 sisyphus [...] cpan.org - Status changed from 'open' to 'resolved'

Fri Jan 21 06:41:28 2011 JAWNSY [...] cpan.org - Correspondence added

Rob, Show quoted text

> The "Subroutine Inline::C::get_parser redefined..." warnings and > associated diagnostic comments have gone, but the "Blindly > untaininting ..." warnings are still there (as I believe it's important > that Inline tells us that it's doing these things).

Reopening for a very quick question: have you considered using Test::Warn? It will ensure the warnings are emitted, while at the same time suppressing them from test output. Not for the redefine warnings (I agree you can/should leave those as-is), but for the blindly untainting warnings that you said *should* be emitted. It seems that if it's expected behaviour, it should be part of your test suite to make sure the behaviour doesn't change. I will also do as you suggest and try the new version shortly. For what it's worth, we currently do have 0.46 in Debian.

Fri Jan 21 06:41:28 2011 The RT System itself - Status changed from 'resolved' to 'open'

Sat Jan 22 00:57:36 2011 sisyphus [...] cpan.org - Correspondence added

RT-Send-CC:

inline [...] perl.org, JAWNSY [...] xcpan.org

On Fri Jan 21 06:41:28 2011, JAWNSY wrote: Show quoted text

> Reopening for a very quick question: have you considered using > Test::Warn? It will ensure the warnings are emitted, while at the same > time suppressing them from test output.

I guess it would be ok to suppress those taint-related warnings from the test suite output (if we can find a satisfactory way of doing that). One way would be to set the config option 'NO_UNTAINT_WARN => 1;' in the test script. However, I'd rather *not* do that in case someone uses that test script as a template, thereby running their scripts with 'NO_UNTAINT_WARN => 1;', totally oblivious to the sorts of things that Inline is doing under the hood. My attempts at using Test::Warn to detect and suppress the warnings have not yet worked: ############################# use warnings; use strict; use Test::More tests => 1; use Test::Warn; use Inline Config => UNTAINT => 1, DIRECTORY => '_Inline_test'; use Inline C => <<'END_OF_C_CODE'; int add(int x, int y) { return x + y; } END_OF_C_CODE warnings_are {add(3,4)} []; ############################# The warnings are issued during Inline's build phase, before the warnings_are() test is run - so I get output of: ############################# 1..1 In Inline::env_untaint() : Blindly untainting tainted fields in %ENV. In Inline::check_config_file(): Blindly untainting Inline configuration file information. In Inline::env_untaint() : Blindly untainting tainted fields in %ENV. In Inline::obj_untaint() : Blindly untainting tainted fields in Inline object. ok 1 ############################# I'll keep looking at this (as time permits) until I either find a way to make it work, or come to an understanding that it can't be made to work. Cheers, Rob

Sun Feb 26 02:58:39 2012 sisyphus [...] cpan.org - Correspondence added

Added Test::Warn to suppress and check the "untainting" warnings in 0.47_01. Thanks for the report and follow-up. Cheers, Rob

Sun Feb 26 02:58:40 2012 sisyphus [...] cpan.org - Status changed from 'open' to 'resolved'

Bug #54825 for Inline: Warnings During Build

Preferred bug tracker