Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Singular/omalloc: do use the system's malloc #4181

Closed
sagetrac-GeorgSWeber mannequin opened this issue Sep 23, 2008 · 12 comments
Closed

Singular/omalloc: do use the system's malloc #4181

sagetrac-GeorgSWeber mannequin opened this issue Sep 23, 2008 · 12 comments

Comments

@sagetrac-GeorgSWeber
Copy link
Mannequin

sagetrac-GeorgSWeber mannequin commented Sep 23, 2008

On both my Mac OS X 10.4 / Xcode 25 boxes, one Intel and one PPC, the following Sage code runs through fine (hit return twice):

sage: for p in prime_range(32768, 100000):  EllipticCurve(GF(p),[0,1,1,10,13]) 

Please note that the length of the interval is almost 70000, so quite some primes are involved.
But if the startpoint of the range is lower the 32768, then Sage crashes, e.g. for:

sage: for p in prime_range(31300, 32600):  EllipticCurve(GF(p),[0,1,1,10,13]) 

(note that the length of the interval is only 1300) one gets the following message with sage crashed:

error: no more memory
System 8672k:8672k Appl 8233k/438k Malloc 4030k/33k Valloc 4608k/404k Pages 1071/81 Regions 9:9

halt 14

The problem/bug can't be due to low physical RAM, or due to not enough virtual RAM for processes, since then the first line of code would have to crash, too. Which is not the case.

It is not related to the mathematical code, since if the length of the interval of primes is only 100 or less, the code runs fine for startpoints above and (!) below 32768.

The bug is triggered also if consecutively several small intervals (below 32768) are calculated, so it seems to be some caching / stack / heap / whatsoever related issue.
It does not seem to occur on platforms other than Mac (OS X 10.4 only?), so I put this under the "porting" issues.

Component: packages: standard

Issue created by migration from https://trac.sagemath.org/ticket/4181

@sagetrac-GeorgSWeber sagetrac-GeorgSWeber mannequin added this to the sage-3.4.1 milestone Sep 23, 2008
@sagetrac-mabshoff

This comment has been minimized.

@sagetrac-mabshoff
Copy link
Mannequin

sagetrac-mabshoff mannequin commented Sep 23, 2008

comment:2

As expected nothing bad happen under valgrind on 64 bit, but I will take a closer look with valgrind running on a 32 bit Linux box. It seems too much of a coincidence to not be related to something close to 2^15-1 or thereabout.

Cheers,

Michael

@sagetrac-GeorgSWeber
Copy link
Mannequin Author

sagetrac-GeorgSWeber mannequin commented Nov 15, 2008

comment:3

Just for the record: once tis ticket is fixed, most probably #3760 will be resolved, too.

@sagetrac-GeorgSWeber
Copy link
Mannequin Author

sagetrac-GeorgSWeber mannequin commented Feb 22, 2009

relies on #5344, apply after this patch after the patch there (to Singular spkg)

@sagetrac-GeorgSWeber
Copy link
Mannequin Author

sagetrac-GeorgSWeber mannequin commented Feb 22, 2009

comment:4

Attachment: trac-4181.patch.gz

Well, what shall I say: apply the two patches (the one from #5344 and this one), and the long standing "long" doctest for "ell_finite_field.py" now succeeds on sage 3.3, finally:

sage -t -long "local/lib/python/site-packages/sage/schemes/elliptic_curves/ell_finite_field.py"
         [53.9 s]
 
----------------------------------------------------------------------
All tests passed!
Total time for all tests: 53.9 seconds

I'll test 666 rings (#3760) in a minute.

Cheers, gsw

@sagetrac-GeorgSWeber sagetrac-GeorgSWeber mannequin changed the title Mysterious error somewhat related to 16-Bit signed integers on Mac OS X Singular/omalloc: do use the system's malloc Feb 22, 2009
@sagetrac-GeorgSWeber sagetrac-GeorgSWeber mannequin modified the milestones: sage-3.4.1, sage-3.4 Feb 22, 2009
@sagetrac-mabshoff
Copy link
Mannequin

sagetrac-mabshoff mannequin commented Feb 22, 2009

comment:5

This will not work and has been tried before. Please do not repurpose tickets since this is not what this ticket is about, but open a new one in case the Singular.spkg needs to be changed. You did that at #5344, but then why change the subject of this ticket?

In general this is a dupe of #3760, so I am closing this as one :)

If you want a less messy ticket to switch to using

Cheers,

Michael

@sagetrac-mabshoff sagetrac-mabshoff mannequin removed this from the sage-3.4 milestone Feb 22, 2009
@sagetrac-mabshoff sagetrac-mabshoff mannequin closed this as completed Feb 22, 2009
@sagetrac-GeorgSWeber
Copy link
Mannequin Author

sagetrac-GeorgSWeber mannequin commented Feb 23, 2009

comment:6

Sure, let's close dupes.

@sagetrac-mabshoff
Copy link
Mannequin

sagetrac-mabshoff mannequin commented Feb 23, 2009

comment:7

Replying to @sagetrac-GeorgSWeber:

Sure, let's close dupes.

Absolutely.

For the record: It only became clear two or maybe three days ago that all these problems on OSX were related to libSingular+mmap, so back in the day when this ticket was opened it was the correct way to do so.

Too bad this path series is being held up by the minpoly bug, but I am hoping someone will fix that issue soon, too.

Cheers,

Michael

@sagetrac-mabshoff
Copy link
Mannequin

sagetrac-mabshoff mannequin commented Feb 23, 2009

comment:8

Hmm, we might need this patch after all, so we can either attach it to another ticket, i.e. #3760, or close that one as a dupe and reopen this one. I will test this patch now on a 32 bit OSX box, so let's wait and see for now.

The whole issue is spread out over too many tickets and has gotten pretty messy, so let's try to get this resolved :)

Cheers,

Michale

@sagetrac-mabshoff
Copy link
Mannequin

sagetrac-mabshoff mannequin commented Feb 23, 2009

comment:9

Ok, reopened and made a blocker against 3.4 again. I am now quite confident we will merge this :)

Cheers,

Michael

@sagetrac-mabshoff sagetrac-mabshoff mannequin removed the c: porting label Feb 23, 2009
@sagetrac-mabshoff sagetrac-mabshoff mannequin added this to the sage-3.4 milestone Feb 23, 2009
@sagetrac-mabshoff
Copy link
Mannequin

sagetrac-mabshoff mannequin commented Feb 23, 2009

comment:10

Positive review. Build on OSX 32 bit, OSX 64 bit, FC 10 and also sage.math. I did valgrind the entire test suite on sage.math.

George's patch is integrated into

http://sage.math.washington.edu/home/mabshoff/SPKG/singular-3-0-4-4-20080711.p4.spkg

Cheers,

Michael

@sagetrac-mabshoff sagetrac-mabshoff mannequin reopened this Feb 23, 2009
@sagetrac-mabshoff
Copy link
Mannequin

sagetrac-mabshoff mannequin commented Feb 24, 2009

comment:11

Merged in Sage 3.4.alpha0.

Cheers,

Michael

@sagetrac-mabshoff sagetrac-mabshoff mannequin closed this as completed Feb 24, 2009
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

0 participants