leif wrote:
Nils Bruin wrote:
On Sunday, May 25, 2014 5:15:08 AM UTC-7, Simon King wrote:
So, it is a tiny amount of memory (~25 byte per round), but I
guess it
should be fixed anyway.
I see a little more memory (~42 bytes). From such a small amount you can
already guess no python objects get leaked, and indeed gc.get_objects()
doesn't report anything unusual.
I'm counting 40 bytes (= 5 64-bit objects) per loop for the given
example, presumably the size of the spolyrec struct returned (i.e.,
allocated and filled) by
singular_polynomial_call(&res, self._poly, _ring, coerced_x,
MPolynomial_libsingular_get_element)
We have
struct spolyrec
{
poly next; // next needs to be the first field
number coef; // and coef the second --- do not change
this !!!
unsigned long exp[VARS]; // make sure that exp is aligned
};
where both 'next' and 'coef' are pointers, and VARS is usually zero, so
'exp' is an "open-ended" array, such that the effective size of the
struct varies.
I did try changing to a=f(1,1,0), [in that case a=0] and then no leak
occurs! So my guess is a leak in libsingular (or our interface with/use
of it), and it's only leaking on construction of non-zero values.
Yes, the leak depends on the values (and the amount also on the field
and the function). My impression is also that it appears whenever
res!=NULL, i.e., the result is non-zero.
The (Sage-)Singular experts will know better to whom it's up to free
what and when...
P.S., forgot to mention:
The code in singular_polynomial_call() (in
src/sage/libs/singular/polynomial.pyx) explicitly prevents Singular from
reclaiming the memory:
...
ret[0] = res_id.m[0]
from_id.m[0] = NULL
res_id.m[0] = NULL
id_Delete(&to_id, r)
id_Delete(&from_id, r)
id_Delete(&res_id, r)
return 0
(from_id.m[0] was set to the input parameter 'p', so that's ok.)
So IMHO either it should make a garbage-collected copy of it (the result
ret / ret[0]) instead, or the caller has to clean up afterwards.
The docstring is quite misleading w.r.t. 'ret', as only the address of a
pointer to be changed is passed to the function, while the struct it
later points to always gets allocated by the callee, not the caller.
-leif
--
() The ASCII Ribbon Campaign
/\ Help Cure HTML E-Mail
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
