[sage-devel] Re: GMP error handling
Hi Jeroen, On 2014-05-27, Jeroen Demeyer wrote: > On 2014-05-25 20:21, Simon King wrote: >> How does GMP handle errors? > Not at all. Oops. > Indeed, Sage has custom memory allocation functions for GMP which can > deal with failed allocations. If the code is properly wrapped within > sig_on()/sig_off(), you will get a Python MemoryError instead. > See http://trac.sagemath.org/ticket/15363 Very good, thank you! Best regards, Simon -- 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.
Re: [sage-devel] GMP error handling
On 2014-05-25 20:21, Simon King wrote: How does GMP handle errors? Not at all. E.g., what happens if an allocation by mpz_init2 fails? Does the program then simply crash? GMP normally crashes in that situation, yes. On the other hand, I see sig_on()/sig_off() around some (but not around all) potentially failing mpz_* function calls in sage/rings/integer.pyx. So, is this enough to deal with errors occurring in GMP, or what else? Indeed, Sage has custom memory allocation functions for GMP which can deal with failed allocations. If the code is properly wrapped within sig_on()/sig_off(), you will get a Python MemoryError instead. See http://trac.sagemath.org/ticket/15363 On a 64-bit system for example: sage: 2^(2^60) --- MemoryError Traceback (most recent call last) in () > 1 Integer(2)**(Integer(2)**Integer(60)) /usr/local/src/sage-git/local/lib/python2.7/site-packages/sage/rings/integer.so in sage.rings.integer.Integer.__pow__ (sage/rings/integer.c:14707)() MemoryError: failed to allocate 144115188075855912 bytes -- 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.
[sage-devel] Re: [sage-release] Re: Sage 6.3.beta2 released
I have reread this thread and I'm asking myself if the ecl upgrade shouldn't have simply bumped the package-version.txt of maxima at patchlevel, thus forcing a rebuild. I mean the author of that ticket surely had the same fail when testing, and the reviewer too? Please tell what I'm missing. Regards, On 26 May 2014 18:00, "Volker Braun" wrote: > You have my attention. We can of course wait with any future releases > until somebody fixes this. > > In an ideal world we would have reliable library versioning, so you > wouldn't need to rebuild maxima UNLESS the ecl library version changes in > an incompatible way (which can be read off from the name). > > > > On Monday, May 26, 2014 3:23:32 PM UTC+1, Jean-Pierre Flori wrote: >> >> >> >> On Monday, May 26, 2014 4:14:56 PM UTC+2, Nathann Cohen wrote: >>> >>> > Open a ticket and someone might feel less lazy :) >>> >>> I don't believe in opening tickets without writing the patch and >>> setting them to needs_review :-P >>> >> Set them to "blocker". >> That will get the release manager attention. >> > -- > You received this message because you are subscribed to the Google Groups > "sage-release" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-release+unsubscr...@googlegroups.com. > To post to this group, send email to sage-rele...@googlegroups.com. > Visit this group at http://groups.google.com/group/sage-release. > For more options, visit https://groups.google.com/d/optout. > -- 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.
[sage-devel] Re: sagemath.org/doc/
Ralf Stephan wrote: Hi, with all the fine changes to docs in 6.2, the web docs are still at 6.1.1. Can you please update the pages? (weekly?) ping -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.
[sage-devel] Re: [sage-release] Re: Sage 6.3.beta2 released
You have my attention. We can of course wait with any future releases until somebody fixes this. In an ideal world we would have reliable library versioning, so you wouldn't need to rebuild maxima UNLESS the ecl library version changes in an incompatible way (which can be read off from the name). On Monday, May 26, 2014 3:23:32 PM UTC+1, Jean-Pierre Flori wrote: > > > > On Monday, May 26, 2014 4:14:56 PM UTC+2, Nathann Cohen wrote: >> >> > Open a ticket and someone might feel less lazy :) >> >> I don't believe in opening tickets without writing the patch and >> setting them to needs_review :-P >> > Set them to "blocker". > That will get the release manager attention. > -- 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.
[sage-devel] Re: Is this memory leak in polynomial evaluation known?
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
numbercoef; // 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.
[sage-devel] Re: update sagemath.desktop; add category
http://trac.sagemath.org/ticket/16400 On Sunday, May 25, 2014 6:51:44 PM UTC+2, arash.kam...@gmail.com wrote: > > Hi, > > Currently, Sage is categorized under '*Other*' on GNU/Linux distros. By > adding the following line to sagemath.desktop we can make it go under its > correct category. > > Categories=Education;Science;Math; > > Here's '*diff*' > 11d10 > < Categories=Education;Science;Math; > > > -- 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.
