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
In Perl 5.26 and above, the /o modifier has side effects on split #16204
Comments
From Harald.Joerg@arcor.deThis is a bug report for perl from Harald.Joerg@arcor.de, #!/usr/bin/perl -w use Test::More; my @records = ( for (@records) { # The next statement is supposed to replace a separator of '0' by # Just verifying what we're going to pass to the split function: my @result = split($separator,$text); is_deeply(\@result,['a','b'],"Resulting in ('a','b')"); done_testing; This is a breakdown from the TWiki (http://twiki.org) test suite. I Flags: Site configuration information for perl 5.26.0: Configured by haj at Fri Aug 11 22:05:56 CEST 2017. Summary of my perl5 (revision 5 version 26 subversion 0) configuration: Locally applied patches: @INC for perl 5.26.0: Environment for perl 5.26.0: |
From @jkeenanOn Fri, 20 Oct 2017 22:59:52 GMT, Harald.Joerg@arcor.de wrote:
I cannot verify your claim that tests were passing with perl-5.24.0 and only started to fail with 5.26.0. In fact, using various versions of perl installed via perlbrew, I got the same results as you going back as far as perl-5.8.9. ##### not ok 4 - Resulting in ('a','b') 132334-split.t 1 256 4 1 4 In fact, it was only when I went back to perl-5.6.1 that I was able to get all tests to PASS. (To use perl-5.6.1, I had to provide an explicit plan for Test::More, as 'done_testing' did not exist nineteen years ago.) ##### In any event, the '/o' modifier is described in 'perldoc perlop' as "largely obsolete." So I would recommend purging it from use in your test suite. Thank you very much. -- |
From @jkeenanuse strict; my @records = ( for (@records) { # The next statement is supposed to replace a separator of '0' by # Just verifying what we're going to pass to the split function: my @result = split($separator,$text); is_deeply(\@result,['a','b'],"Resulting in ('a','b')"); #done_testing; |
The RT System itself - Status changed from 'new' to 'open' |
From @cpansproutOn Fri, 20 Oct 2017 16:36:47 -0700, jkeenan wrote:
I get that same failure with 5.24.2 and 5.22.4, but I get a different failure with 5.20.3: not ok 4 - Resulting in ('a','b') (This time it fails on the first element of the array.) 5.18.3 gives the same results as 5.20.3. All of those are non-threaded builds. My 5.14.4 and 5.24.1 installations are threaded and give the following: $ pbpaste|perl5.14.4 So it seems we have a discrepancy in behaviour between threaded and non-threaded builds, which is definitely a bug.
Which is a bit of an exaggeration, in my opinion.
Nevertheless, it is a bug, and should be fixed, since /o is not deprecated. -- Father Chrysostomos |
From @jkeenanOn Sat, 21 Oct 2017 00:12:58 GMT, sprout wrote:
Agreed. Building a threaded perl at tag v5.24.0 and running that test file, I get all tests PASSing. My unthreaded perl-5.24.1 had a FAIL on the 4th test. So, is the original poster's test setup "correct" -- in the sense that having all 4 tests pass is the expected behavior? Harald.Joerg: Do you know which of your perl builds were threaded and which were not?
-- |
From @iabynOn Fri, Oct 20, 2017 at 05:12:58PM -0700, Father Chrysostomos via RT wrote:
I haven't looked too closely, but this looks like another #129158 "null ptr deref, segfault in Perl_pp_split () at pp.c:5738" It turns out that this is another variant of RT #124368: on -- |
From Harald.Joerg@arcor.de"James E Keenan via RT" <perlbug-followup@perl.org> writes:
Sure! I have to apologize: *with a non-threaded 5.24.3, the fourth test The test succeeds with: (v5.26.1) built for x86_64-linux-thread-multi The test fails with: The "gnu-thread" Perls are what's distributed with Debian 8/9, all the |
From @tonycozOn Sat, 21 Oct 2017 09:54:22 -0700, Harald.Joerg@arcor.de wrote:
This might have been fixed by 3cb4cde Tony |
From @jkeenanOn Sat, 28 Oct 2017 08:10:56 GMT, tonyc wrote:
I believe it has been fixed. Here are the results of running test file at commit eecd4d1 on non-threaded, then threaded builds on Linux. ##### ##### Questions: 1. Are the tests added as part of 3cb4cde sufficient to demonstrate that the problem has been solved? Or should we add a variant of the test file above to the test suite? 2. Should this be backported to 5.24 and 5.26? Thank you very much. |
From @tonycozOn Sat, Oct 28, 2017 at 06:35:12AM -0700, James E Keenan via RT wrote:
A test specific this case might be useful.
No, it changes behaviour for non-threaded builds (when it doesn't Tony |
From @jkeenanOn Sun, 29 Oct 2017 00:36:22 GMT, tonyc wrote:
Test adapted from original poster's code added in commit 6e8135a.
Marking ticket Resolved. Thank you very much. |
@jkeenan - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#132334 (status was 'resolved')
Searchable as RT132334$
The text was updated successfully, but these errors were encountered: