Changes between Version 2 and Version 3 of Ticket #21388


Ignore:
Timestamp:
09/02/16 08:45:59 (17 months ago)
Author:
jdemeyer
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #21388 – Description

    v2 v3  
    55I don't know if that function needs to be implemented the way it is--it's possible that it could be reworked from the ground up to not need this work-around, but I don't know.  I still don't understand the coercion model well-enough.
    66
    7 But in brief, the crash occurs because we have (in the original code) a large element of "Univariate Quotient Polynomial Ring in v over `Multivariate Polynomial Ring in x, u over Rational Field with modulus v^2 - u^4 + 10*u^3 + 3*u^2 - 4*u + 8`.  This is then being cast simply to a multivariate rational polynomial over x, u, v.  Because there is no direct coercion between these types this involves `eval()`-ing the polynomial as a Python expression.
     7But in brief, the crash occurs because we have (in the original code) a large element of `Univariate Quotient Polynomial Ring in v over Multivariate Polynomial Ring in x, u over Rational Field with modulus v^2 - u^4 + 10*u^3 + 3*u^2 - 4*u + 8`.  This is then being cast simply to a multivariate rational polynomial over x, u, v.  Because there is no direct coercion between these types this involves `eval()`-ing the polynomial as a Python expression.
    88
    99The problem is that this expression can become too large for the stack--specifically in Python's symbol visibility analysis, a step it performs just before compiling an expression to bytecode.  The implementation of that recurses into binary expressions, leading to a stack overflow for such a large expression.  This issue has come up once before in #16014 where it was worked around by a rewrite of the code.  This particular test worked on Linux where the default stack size is 8MB, but it crashed on Windows where the typical stack is just 1MB.