Opened 13 years ago

Closed 12 years ago

Last modified 12 years ago

#3760 closed defect (fixed)

creating 666 rings in singular fails with an out of memory error on 32-bit intel os x.

Reported by: was Owned by: was
Priority: critical Milestone: sage-3.4
Component: number theory Keywords:
Cc: Merged in:
Authors: Reviewers:
Report Upstream: Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Status badges

Description

Trying:
    for p in prime_range(Integer(10000)):           #long time (~20s)###line 1014:_sage_    >>> for p in prime_range(10000):           #long time (~20s)
          if p != Integer(389):
              G=E.change_ring(GF(p)).abelian_group()
Expecting nothing

error: no more memory
System 5116k:5116k Appl 4666k/449k Malloc 4088k/3k Valloc 1024k/445k Pages 159/97 Regions 2:2

halt 14  

         [19.0 s]
exit code: 768

----------------------------------------------------------------------
The following tests failed:


        sage -t -long --verbose devel/sage/sage/schemes/elliptic_curves/ell_finite_field.py
Total time for all tests: 19.0 seconds
bsd:sage-3.1.alpha0 was$ 

Change History (12)

comment:1 Changed 13 years ago by cremona

Could someone with 32-bit intel os x try this again, since it is possible that the patch for #3961 (merged in 3.1.2.alpha2) fixes this.

If not I can try to look into it but I'm not sure how to as it works fine on my laptop.

comment:2 Changed 13 years ago by mabshoff

#4179 is a duplicate of this ticket and has some additional info.

Cheers,

Michael

comment:3 Changed 12 years ago by GeorgSWeber

Just for the record: I had tried to get a grip on this issue, the outcome is trac ticket #4181 --- once that ticket is fixed, this one will (most probably) be resolved, too. Hopefully.

Cheers,
gsw

comment:4 Changed 12 years ago by mabshoff

The following code specifically seems to expose the problem:

E = EllipticCurve('389a')
for p in prime_range(Integer(10000)): 
    if p != Integer(389):
        G=E.change_ring(GF(p)).abelian_group()

On sage.math the memory increase is about 70 MB with Sage 3.2.2.rc0, so I have no idea how this could fail on OSX.

Cheers,

Michael

comment:5 Changed 12 years ago by was

This exposes the problem much more clearly on my MacBook? Pro:

teragon:sage-3.3.rc2 wstein$ sage
----------------------------------------------------------------------
| Sage Version 3.3.rc2, Release Date: 2009-02-17                     |
| Type notebook() for the GUI, and license() for information.        |
----------------------------------------------------------------------
sage: E = EllipticCurve('389a')
sage: time v = [E.change_ring(GF(p)) for p in prime_range(10000) if p != 389]

error: no more memory
System 5120k:5120k Appl 4638k/481k Malloc 4095k/0k Valloc 1024k/480k Pages 153/103 Regions 2:2

halt 14

comment:6 Changed 12 years ago by was

  • Summary changed from sage -t -long ell_finite_field.py fails with an out of memory error on 32-bit intel os x. to creating 666 rings in singular fails with an out of memory error on 32-bit intel os x.

This is really a problem with Singular. It has nothing to do with elliptic curve:

teragon:sage-3.3.rc2 wstein$ sage
----------------------------------------------------------------------
| Sage Version 3.3.rc2, Release Date: 2009-02-17                     |
| Type notebook() for the GUI, and license() for information.        |
----------------------------------------------------------------------
sage: v = prime_range(4974); len(v)
666
sage: w = [GF(p)['x,y'] for p in v]

error: no more memory (mminit.cc)
System 4608k:4608k Appl 4510k/97k Malloc 4093k/2k Valloc 512k/95k Pages 121/7 Regions 1:1

halt 14
teragon:sage-3.3.rc2 wstein$ uname -a
Darwin teragon.local 9.6.0 Darwin Kernel Version 9.6.0: Mon Nov 24 17:37:00 PST 2008; root:xnu-1228.9.59~1/RELEASE_I386 i386

Argh!

comment:7 Changed 12 years ago by was

By the way, it says "mminit.cc" in the above, since I hardcoded that into the singular library -- the message is being printed from a hardcoded message in mminit.cc in the singular *kernel*.

comment:8 Changed 12 years ago by GeorgSWeber

  • Milestone changed from sage-3.4.1 to sage-3.4
  • Summary changed from creating 666 rings in singular fails with an out of memory error on 32-bit intel os x. to [patches at #5344, #4181] creating 666 rings in singular fails with an out of memory error on 32-bit intel os x.

Yippieh:

sage: v = prime_range(4974); len(v)
666
sage: w = [GF(p)['x,y'] for p in v]
sage: 

comment:9 Changed 12 years ago by mabshoff

  • Milestone changed from sage-3.4 to sage-3.4.1
  • Priority changed from blocker to critical
  • Summary changed from [patches at #5344, #4181] creating 666 rings in singular fails with an out of memory error on 32-bit intel os x. to creating 666 rings in singular fails with an out of memory error on 32-bit intel os x.

Unless someone fixes #5344 in the next 24 hours this will not go into 3.4.

Cheers,

Michael

comment:10 Changed 12 years ago by GeorgSWeber

For the record:

The underlying problem is now known: Singular/omalloc relies on a version 2.6.5 of dlmalloc from 1998, and that version behaves bad on Macs.

In the course of the investigation, another Singular/kernel bug got in the way.

I think I know how to *circumvent* this Singular/kernel bug ("just" drop in the recent dlmalloc 2.8.3 at the place of the old version, and/or prevent omalloc's "configure" from setting the macro "OMALLOC_USES_MALLOC"), but I thought I try and fix that other bug first.

BTW: From the historical remarks in v2.8.3 in dlmalloc it seems plausible that the old v2.6.5 is the culprit also for the bad behaviour on Fedora 9/10 systems --- but this is ticket #5278. Which probably should be closed as a dupe (to this ticket here).

comment:11 Changed 12 years ago by mabshoff

  • Resolution set to fixed
  • Status changed from new to closed

Fixed in Sage 3.4.alpha0 via #4181 and #5344.

Cheers,

Michael

comment:12 Changed 12 years ago by mabshoff

  • Milestone changed from sage-3.4.1 to sage-3.4
Note: See TracTickets for help on using tickets.