#11771: sage crashes on some degenerate flint xgcd's
--------------------------------+-------------------------------------------
Reporter: lftabera | Owner: AlexGhitza
Type: defect | Status: needs_review
Priority: critical | Milestone: sage-4.7.2
Component: basic arithmetic | Keywords: flint, crash, xgcd fmpq_poly
rational polynomials
Work_issues: | Upstream: N/A
Reviewer: | Author: Leif Leonhardy
Merged: | Dependencies:
--------------------------------+-------------------------------------------
Comment(by leif):
Replying to [comment:20 spancratz]:
> I can confirm that the patch suggested by leif does the right thing. It
does have one extra re-allocation, though, which isn't necessary. I
suggest the following,
>
{{{
limbs = FLINT_MAX(fmpz_size(s->den), fmpz_size(t->den)) +
fmpz_size(rop->den);
temp = fmpz_init(limbs);
}}}
Well, I think something like that led to the problem we had, as the sizes
can change inbetween. The reallocation should be a nop in at least half of
the cases, and I think doesn't have a major impact on the overall
performance of the function. It is safe(r) at any rate.
[[BR]]
> Also, the two subsequent calls to fmpq_poly_canonicalize() should be
replaced by
{{{
fmpq_poly_canonicalize(s, NULL);
fmpq_poly_canonicalize(t, NULL);
}}}
>
> If you look at the code for fmpq_poly_canonicalize() you'll see that
this is in fact not necessary at all since the function doesn't ever
actually use the temporary space passed in anyway. --- I realise this
looks rather bad. If you think this should be cleaned up on the occasion
of this ticket, let me know. ---
I'd prefer making such changes on another ticket.
[[BR]]
> In any case, the above bit of code fixes this issue.
I haven't really checked the sizes of other variables...
[[BR]]
> By the way, the tight re-use of fmpz variables in flint1 together with
the manual memory management is one of the biggest pains when working with
flint1. This is all much, much easier in flint2.
I know. I was first confused by the fact that `foo=fmpz_init(n)` gives
random values for `fmpz_size(foo)`, so one really has to keep track of the
"real" sizes (the amount of memory allocated) separately, or perhaps just
on the semantic level, not actually available to the code, at least not
directly through the `fmpz` interface.
Doing so is error-prone, but in general more efficient though, as the
functions you use can omit frequent checks, relying on that you know what
you're doing...
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/11771#comment:22>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
