#13447: Make libsingular multivariate polynomial rings collectable
----------------------------------------------------------------+-----------
       Reporter:  nbruin                                        |         
Owner:  rlm                            
           Type:  defect                                        |        
Status:  needs_review                   
       Priority:  major                                         |     
Milestone:  sage-5.4                       
      Component:  memleak                                       |    
Resolution:                                 
       Keywords:                                                |   Work 
issues:  Input from a libsingular expert
Report Upstream:  None of the above - read trac for reasoning.  |     
Reviewers:                                 
        Authors:  Nils Bruin, Simon King                        |     Merged 
in:                                 
   Dependencies:                                                |      
Stopgaps:                                 
----------------------------------------------------------------+-----------
Changes (by {'newvalue': u'Nils Bruin, Simon King', 'oldvalue': ''}):

  * status:  needs_info => needs_review
  * work_issues:  Input from libsingular experts => Input from a
                  libsingular expert
  * author:  => Nils Bruin, Simon King


Old description:

> Presently, #715 + #11521 help not permanently keeping parent in memory.
> In the process we uncovered a hard-but-consistently triggerable problem
> with the collection of `MPolynomialRing_libsingular`. We have only
> observed the problem on `bsd.math.washington.edu`, MacOSX 10.6 on x86_64.
>
> The present work-around is to permanently store references to these upon
> creation, thus preventing collection. It would be nice if we could
> properly solve the problem (or at least establish that the problem is
> specific to `bsd.math`)
>
> Apply [attachment:trac_13447-consolidated_refcount.patch]

New description:

 Presently, #715 + #11521 help not permanently keeping parent in memory. In
 the process we uncovered a hard-but-consistently triggerable problem with
 the collection of `MPolynomialRing_libsingular`. We have only observed the
 problem on `bsd.math.washington.edu`, MacOSX 10.6 on x86_64.

 The present work-around is to permanently store references to these upon
 creation, thus preventing collection. It would be nice if we could
 properly solve the problem (or at least establish that the problem is
 specific to `bsd.math`)

 '''Unmerge''' #13145

 Apply

  * [attachment:trac_13447-consolidated_refcount.patch]
  * [attachment:trac_13447-modulus_fix.patch]
  * [attachment:trac_13447-rely_on_singular_refcount.patch]

 '''Merge together with''' #715, #11521

--

Comment:

 I have provided a new patch, that removes the custom refcounter, using
 Singular's refcounter (ring.ref) instead.

 As I have announced, I also fixed the failing modular symbols test, by
 computing the dimension before displaying it: The test previously worked
 ''only'' because a computation happened in a different test that happened
 to be executed early enough, that side effect being possible because Hecke
 modules would stay in memory permanently.

 I did not run the full test suite yet. But
 sage/rings/polynomial/plural.pyx and
 sage/rings/polynomial/multi_polynomial_libsingular.pyx and
 sage/modular/modsym/ambient.py all work.

 Problems for the release manager and the reviewer:

  * I removed the custom refcounting. But there were tests using the custom
 refcounters. The original tests demonstrated that the underlying c-data
 (the libsingular ring) is properly deleted. I replaced them by tests
 showing that the `MPolynomialRing_libsingular` get garbage collected. Is
 that OK from your point of view?

  * The mentioned tests will ''only'' work with #715 and #11521, because
 they are responsible for making polynomial rings garbage collectable.
 Hence, #13477 and #715 and #11521 need to be merged together; just having
 #715 and #11521 would result in the OS X problem we encountered, and
 #13447 alone would have two failing tests.

  * #13145 has already been merged in sage-5.4.beta1. I suggest to unmerge
 it, because it uses the old unreliable "double refcount" approach. My new
 patch also takes care of refcounting of plural rings.

 Apply trac_13447-consolidated_refcount.patch trac_13447-modulus_fix.patch
 trac_13447-rely_on_singular_refcount.patch

-- 
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/13447#comment:33>
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.

Reply via email to