base/lex test 41 failure under "make minitest" in some platforms #15480
Comments
From @jhiThis one test in line 191 of t/base/lex.t fails in some (not all) platforms under "make minitest" like this ... (all other tests in the file pass) or if run explicitly like this: (cd t && ./perl -Ilib TEST -v base/lex.t) So the difference is two source code lines. What is mystifying is two things: (1) the test fails only on a seemingly random selection of platforms: AIX 5 on PPC, Debian on PPC, and Solaris on Sparc. While passing fine on e.g. Solaris on x86, and Ubuntu on x86. [*] (2) the test has been there from time immemorial (Sarathy) -- so something recentish on the lexer/parser? I know for a fact that some months ago the test must have been passing, I just haven't done a wide testing recently. [*] The CPU is a red herring, I hope. It just reflects the selection of platforms I have access to. I hope. |
From @jkeenanOn Wed Jul 27 04:44:43 2016, jhi wrote:
I can reproduce this on my old iBook G4 -- Darwin/PPC. Since I cannot recall ever running 'make minitest' on this machine, I can't say when the problem first appeared. I'll attach the 'perl -V' for the full build of the commit at which I tested blead as well as the individual test failures. Thank you very much. -- |
From @jkeenanSummary of my perl5 (revision 5 version 25 subversion 4) configuration: Characteristics of this binary (from libperl): |
From @jkeenant/base/lex ... 1..107 |
|
The RT System itself - Status changed from 'new' to 'open' |
From @cpansproutOn Wed Jul 27 04:44:43 2016, jhi wrote:
Which is inside an eval, and is on line 6 of that eval. T() checks the caller’s line number.
It does seem odd that the line number would be off only on some platforms. The last commit in toke.c to touch line numbers was b3dd0ab. Can you check whether that was it? Also, if you reduce the amount of code in that string eval leading up to the T() in question, does the problem persist? -- Father Chrysostomos |
From @jkeenanOn Wed Jul 27 06:17:48 2016, jkeenan wrote:
Note: On this same system, when I attempt a full 'make test_harness', I am getting failures in t/comp/parser.t which I have not previously gotten (e.g., which I didn't get when testing 5.24.0). These test failures all relate to heredocs -- which, given recent work in that area -- may explain the recency of these failures. I am re-testing and will post relevant findings. Thank you very much. -- |
From @jkeenanPrompted by Jarkko's reports of failures in t/base/lex.t during 'make minitest' (https://rt.perl.org/Public/Bug/Display.html?id=128747), I ran 'make minitest' for the first time ever and confirmed his failures reports for Darwin/PPC. I then ran a regular 'make test_harness' on that machine and was surprised to see failures in both t/base/lex.t and t/comp/parser.t. I reconfigured and rebuilt and got the following 5 failures in t/comp/parser.t: ##### I know that 'make test' ran successfully on this machine when I went to install 5.24.0. I'm fairly certain that I built and tested blead on this machine about a month ago. Hence, my suspicion is that these failures are due to whatever work has recently been merged into blead related to heredocs. With the same build as above I am also getting a test failure in t/base/lex.t even outside of 'make minitest': ##### This is the same failure as reported by Jarkko in RT #128747, so the problem is not confined to 'make minitest'. I stress again that this failure is new; all tests for the installation of 5.24.0 passed. Thank you very much. -- |
From @jkeenanSummary of my perl5 (revision 5 version 25 subversion 4) configuration: Characteristics of this binary (from libperl): |
From @jkeenanOn Wed Jul 27 09:41:10 2016, jkeenan wrote:
I have built both perl-5.25.2 and perl-5.25.3 on Darwin/PPC. I can confirm that *neither* of these test failures occurs in *either* of those tags. Hence, I infer that the test failures have been introduced since perl-5.25.3. Thank you very much. |
From @cpansproutOn Wed Jul 27 11:52:49 2016, jkeenan wrote:
Thank you. That saved me time. I do have access to a G4, but it doesn’t have git, so I did a manual ‘bisect’ and it led to v5.25.3-28-g6745174: commit 6745174 parser.h: Use UV for string delims I don’t understand why that would throw line numbers off. I’ll look into it. -- Father Chrysostomos |
|
The RT System itself - Status changed from 'new' to 'open' |
From @jhi
The CPU may not be a red herring, given that James Keenan is seeing the same in darwin/ppc. PPC... Sparc... Endianness? Are we storing the line number somewhere and then reading it through a wrong cast, or something? Trying to think when did I last test all these platforms ... I am not certain ... but quite certain all worked at 5.24.0. |
From @jkeenanOn Wed Jul 27 08:50:43 2016, jkeenan wrote:
As noted in https://rt-archive.perl.org/perl5/Ticket/Display.html?id=128753, on Darwin/PPC this test failure started to appear after tag v5.25.3. -- |
From @cpansproutOn Wed Jul 27 16:16:41 2016, jhi wrote:
As I noted in ticket #128753, it was commit 6745174. This is getting confusing, so I am going to merge the tickets, since the failures they describe (though in different tickets) are the same (line numbers screwy after s//<<end/e). -- Father Chrysostomos |
From @cpansproutOn Wed Jul 27 17:16:08 2016, sprout wrote:
Pretty close to that.
which changed PL_multi_close to UV, but failed to change SAVEI8(PL_multi_close); in S_sublex_done. I’ll have a fix pushed within a few hours (I hope). -- Father Chrysostomos |
From @cpansproutOn Wed Jul 27 18:28:04 2016, sprout wrote:
No, actually it was *exactly* that.
Fixed in 2ca4363. -- Father Chrysostomos |
|
@cpansprout - Status changed from 'open' to 'resolved' |
From @jkeenanOn Wed Jul 27 08:50:43 2016, jkeenan wrote:
On Darwin/PPC, both these tests are passing as of commit 555e2b1. Marking ticket resolved. Thank you very much. |
Migrated from rt.perl.org#128747 (status was 'resolved')
Searchable as RT128747$
The text was updated successfully, but these errors were encountered: