Changes between Initial Version and Version 2 of Ticket #21388
 Timestamp:
 09/02/16 08:45:31 (23 months ago)
Legend:
 Unmodified
 Added
 Removed
 Modified

Ticket #21388

Property
Status
changed from
new
toneeds_review

Property
Status
changed from

Ticket #21388 – Description
initial v2 5 5 I don't know if that function needs to be implemented the way it isit's possible that it could be reworked from the ground up to not need this workaround, but I don't know. I still don't understand the coercion model wellenough. 6 6 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.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. 8 8 9 9 The problem is that this expression can become too large for the stackspecifically 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.