# Changes between Initial Version and Version 2 of Ticket #21388

Ignore:
Timestamp:
09/02/16 08:45:31 (2 years ago)
Comment:

Unmodified
Removed
Modified
• ## Ticket #21388

• Property Status changed from `new` to `needs_review`
• ## Ticket #21388 – Description

 initial I 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. 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. 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. The 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.