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
For loop fails to CATCH exception on 208th iteration in Rakudo #3759
Comments
From @masak<[Tux]> Something recent broke Text::CSV :( |
From @masakmasak (>):
I did a bisect, which revealed a number of things. All of the findings below can be reproduced by the following commands: $ git clone git@github.com:rakudo/rakudo First off, here's the offending commit. Its parent runs all the way undisturbed, but this commit dies after 28 iterations: commit a398910b4a6a1bdd42cd5a3cc33d8dfad0e3501f Better handling of sink. src/Perl6/Actions.nqp | 29 ++--------------------------- What's interesting is that the commit is not an NQP/Moar bump, it's just the addition of a new op. So chances are the commit uncovered an error that was already present. I tried reverting this commit on Rakudo HEAD (c86f75), and the resulting commit doesn't have the bug. I pushed the result to the branch 'revert-bho-sink' on Github, in case someone wants to merge this into 'nom'. (Which is my recommendation.) I haven't spectested the new commit. Next up, the following commit changes the number of iterations from 28 to 32: commit a1a236067b805961e742e1b51fa2ffbc274f90c4 Get latest NQP and MoarVM improvements. tools/build/NQP_REVISION | 2 +- This commit pulls in the following NQP commits (reverse chronological order): 183e611 Use new MoarVM static block lexicals support. And that 9267ba7 bump commit pulls in the following Moar commits: f25affb MAST nodes can be identified by exact type. Beyond noting that there are several spesh-related changes in there, I don't find anything particular in that list that stands out as a suspect. Later on, another bump commit changes the number of iterations from 32 to 207: commit dd131050268bc63044868689df487fcc47e841de Bump NQP_REVISION to get latest MoarVM. The commit pulls in only one NQP commit, which in turn pulls in these Moar commits: a752064 Bump OSR theshold also. This one is easier to explain. One of the optimization thresholds is changed from 25 to 200 in e2e908b. 25+7 == 32 and 200+7 == 207. So a decent guess is that an optimization kicks in after 207 iterations, and creates code that fails to catch the exception. There, that's a bunch of grunt work done. :) Hopefully minds sharper that mine can look at the a39891 commit and go "ah! that's what's wrong!". |
From @masak<masak> so, I just removed https://github.com/rakudo/rakudo/blob/nom/src/vm/moar/Perl6/Ops.nqp#L460 locally; RT #124191 is still present afterwards :/ |
From @jnthnOn Sun Mar 29 12:52:28 2015, masak wrote:
It was a MoarVM dynamic optimization bug involving a wrongly handled interaction between inlining and exception handlers. Fixed it in MoarVM, and added a test in S04-exception-handlers/catch.t. |
The RT System itself - Status changed from 'new' to 'open' |
@jnthn - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#124191 (status was 'resolved')
Searchable as RT124191$
The text was updated successfully, but these errors were encountered: