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
Comments
This comment has been minimized.
This comment has been minimized.
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 Cheers, Michael |
comment:3
Just for the record: once tis ticket is fixed, most probably #3760 will be resolved, too. |
relies on #5344, apply after this patch after the patch there (to Singular spkg) |
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:
I'll test 666 rings (#3760) in a minute. Cheers, gsw |
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 |
comment:6
Sure, let's close dupes. |
comment:7
Replying to @sagetrac-GeorgSWeber:
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 |
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 |
comment:9
Ok, reopened and made a blocker against 3.4 again. I am now quite confident we will merge this :) Cheers, Michael |
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 |
comment:11
Merged in Sage 3.4.alpha0. Cheers, Michael |
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):
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:
(note that the length of the interval is only 1300) one gets the following message with sage crashed:
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
The text was updated successfully, but these errors were encountered: