To not hijack Erik's original thread on GMP/MPIR-related issues with
/Singular on Cygwin/, this is a follow-up concerning just building Sage
with its GMP package (instead of MPIR, which is the default).
Sage's optional gmp package is currently GMP 5.1.3 (i.e., quite old).
leif wrote:
> leif wrote:
>> Erik Bray wrote:
>>> On Thu, Jul 28, 2016 at 8:03 PM, Erik Bray <erik.m.b...@gmail.com>
wrote:
>>>> On Thu, Jul 28, 2016 at 4:32 PM, Erik Bray <erik.m.b...@gmail.com>
wrote:
>>>>> ...and in particular, are any omalloc experts watching this list?
>>>>>
>>>>> I ask because my current issue in the Cygwin port of Sage is a
>>>>> segfault that's occurring in Singular during a routine memory
>>>>> deallocation of GMP integers.
>>>>>
>>>>> I'm working on getting a Singular compiled without omalloc to see if
>>>>> that makes any difference. In the meantime I just thought I'd reach
>>>>> out to see what expertise I have to draw on in the community.
>>>>
>>>> Thanks everyone for all the tips. I'm heading out for vacation again
>>>> but will be back in a week and will go through them one by one.
>>>>
>>>> For what it's worth I think I'm close in on the problem:
>>>>
>>>> The way Singular is being built and/or how DLLs are being loaded it's
>>>> ending up with both GMP and MPIR simultaneously, and this causes a
>>>> great deal of confusion, not the least of which that
>>>> mp_set_memory_functions is being called in one but not the other.
>>>>
>>>> The end result is a segfault on a memory address that was allocated
>>>> with the system allocator, but is being freed by omalloc.
>>>>
>>>> Not sure why this is happening but it must be a build issue.
>>>
>>> I just completed a build of Singular where I had forcibly changed all
>>> instances of -lgmp to -lmpir in the makefiles, and it works now, so
>>> that's reassuring.
>>
>> When you're back, you could try building Sage with the optional GMP
>> package*. I'm curious as to whether you'll then get two instances of
>> GMP...
>>
>> (The optional package is still at 5.1.3 IIRC though, but until then I'll
>> perhaps have upgraded it to GMP 6.1.1.)
>
> Just be warned: Building Sage with its GMP package appears to be broken.
>
> First of all, it's not sufficient to reconfigure with --with-mp=gmp and
> rerun 'make' (which was, AFAIK, supposed to or intended to work).
>
> Running 'make build-clean' and then reconfiguring doesn't work either;
> presumably that doesn't rebuild everything that it should. (Gave
> hundreds of crashes and timeouts in ptestlong IIRC, among them glibc
> detected invalid free()s and realloc()s of python.)
>
> Deleting local/var/lib/sage/installed/* in advance "worked", but gave
> trouble in the build (e.g. gf2x's tuning consistently failed with an
> assertion error). With GCC 6.1. at least, the build finally succeeded
> (is installing sagetex-3.0 with SAGE_CHECK=yes supposed to work?), but
> docbuilding got stuck, leaving 1 to N (-jN) python processes, 1 or N-1
> running 100% without any progress even after hours. (I also retried a
> couple of times.)
>
> On a similar system, I did build Sage 7.3.rc0 with SAGE_INSTALL_GCC=yes
> and --with-mp=gmp from scratch, which led to a couple of doctest errors,
> most of them "harmless" I think, but also crashes in e.g. libsingular.
Back on the other system, I did the same (again), this time with GCC 5.4.
Now the build went smooth except for GSL's testsuite now failing
(something I've seen in the past on other systems as well); sagetex's
testsuite in contrast now passed, tuning gf2x also worked, and
docbuilding succeeded without any issues.
But in ptestlong I'm getting the same (I think) failures as on the other
machine (where I built with Sage's GCC, 4.9.3):
----------------------------------------------------------------------
sage -t --long src/doc/en/constructions/algebraic_geometry.rst # 1
doctest failed
sage -t --long src/doc/en/developer/coding_in_other.rst # 1 doctest failed
sage -t --long src/sage/ext/memory.pyx # 1 doctest failed
sage -t --long src/sage/matrix/matrix_double_dense.pyx # 1 doctest failed
sage -t --long src/sage/libs/gap/assigned_names.py # 1 doctest failed
sage -t --long src/sage/rings/integer.pyx # 1 doctest failed
sage -t --long src/sage/structure/sage_object.pyx # Killed due to abort
----------------------------------------------------------------------
(Ignore the fourth and 5th errors; the former is [still] due to numeric
noise, the latter *always* fails on first try, passes when rerun.)
Some may be known issues ("harmless" doctest failures but also more
severe ones); the comments on the ticket upgrading the optional GMP
package to 5.1.3 [1] and its follow-up [2] aren't all that clear to me,
especially regarding the outcome when the ticket(s) got merged.
-leif
[1] https://trac.sagemath.org/ticket/12661
[2] https://trac.sagemath.org/ticket/15957
--
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 https://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/d/optout.
