New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
assertion failures when running with -t switch and tainted @INC #10105
Comments
From @ntyniThis is a bug report for perl from Niko Tyni <ntyni@debian.org>, A suitable combination of tainted @INC, the '-t' switch and stubs for Originally reported as http://bugs.debian.org/565703, reproducible % ./perl -t -Ilib -e 'unshift @INC, shift; require Fcntl' foo Other variants include % echo 'XSLoader::load(q(Fcntl))' > T.pm && ./perl -Ilib -MXSLoader -I. -t -e 'unshift @INC, shift; require T; *a = \&{"Fcntl::S_IFWHT"}' foo and % echo 'XSLoader::load(q(POSIX))' > T.pm && ./perl -Ilib -MXSLoader -I. -t -e 'unshift @INC, shift; require T; *a = \&{"POSIX::CLK_TCK"}' foo which fails in the same way. The problem seems to be related to the stubs for undefined constants; ./perl -Ilib -MPOSIX -E 'say POSIX::CLK_TCK' Blead backtrace of the first case: Core was generated by `./perl -t -Ilib -e unshift @INC, shift; require Fcntl foo'. Flags: Site configuration information for perl 5.11.4: Configured by niko at Sun Jan 24 20:28:38 EET 2010. Summary of my perl5 (revision 5 version 11 subversion 4) configuration: Locally applied patches: @INC for perl 5.11.4: Environment for perl 5.11.4: |
From @iabynOn Sun, Jan 24, 2010 at 11:02:46AM -0800, Niko Tyni wrote:
This appears to have been introduced in 5.10.0 -- |
The RT System itself - Status changed from 'new' to 'open' |
From @iabynOn Sun, Jan 24, 2010 at 11:02:46AM -0800, Niko Tyni wrote:
I can trigger the same assertion failure with the following simplified $ cat /tmp/Foo.pm $ ./perl -t -I/tmp -e 'unshift @INC, $^X; require Foo' It boils down to: commit 885ffcb Assert that SvMAGIC() isn't being called on PVMGs which are using the ... @@ -1164,6 +1164,8 @@ the scalar's value cannot change unless written to. I'm assuming, Nicholas, that this assertion is correct, and thus its the In which case, its a bit unclear to me what to do. Doing a whole compi;e I would speculate that the other reported assertion failures have a Anyway, probably not something for 5.12, even though its a 5.10 regression. -- |
From @rgarciaOn 9 February 2010 01:17, Dave Mitchell <davem@iabyn.com> wrote:
Yes, that sounds like a reasonable line in the sand to draw. Code |
From @iabynOn Tue, Feb 09, 2010 at 12:52:48PM +0100, Rafael Garcia-Suarez wrote:
(note to self) This might also be related to http://www.perlmonks.org/?node_id=822374 So I'll need to check that too when I get round to fixing it. -- |
From @nwc10On Tue, Feb 09, 2010 at 12:52:48PM +0100, Rafael Garcia-Suarez wrote:
Yes, and yes. Otherwise you end up with pointers which half the core code thinks point
This seems like the best solution. Nicholas Clark |
From @ntyniOn Sun, Jan 24, 2010 at 11:02:46AM -0800, Niko Tyni wrote:
This crash seems to have been fixed since. Bisecting gives commit 0f94cb1 [perl #123223] Make PADNAME a separate type So this ticket can probably be closed? Thanks, |
@iabyn - Status changed from 'open' to 'resolved' |
From @iabynOn Fri, Apr 29, 2016 at 09:23:41AM +0300, Niko Tyni wrote:
Closed now, thanks. -- |
Migrated from rt.perl.org#72330 (status was 'resolved')
Searchable as RT72330$
The text was updated successfully, but these errors were encountered: