On Thu, Aug 4, 2016 at 11:26 AM, leif <not.rea...@online.de> wrote:
> Erik Bray wrote:
>> On Sat, Jul 30, 2016 at 8:25 PM, leif <not.rea...@online.de> 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.
>>
>> To be honest I'm not even sure how I ended up with GMP in my Sage
>> install in the first place. I never did --with-mp=gmp. Or is that
>> what the --enable-gmpcompat flag to MPIR's configure does? Regardless
>> the end result is two complete copies of the library (I would have
>> thought just a symlink from mpir to gmp or something).
>>
>> Singular links explicitly against "gmp", while many other packages are
>> linked to "mpir". In the end both are being loaded and some symbols
>> being resolved to one, while other symbols resolved to the other.
>> It's very confusing.
>
> We removed any explicit mention of MPIR ('-lmpir', '#include <mpir.h>')
> a while ago, but a few newer packages may indeed recognize MPIR
> meanwhile and link to that instead. But I'm not aware of a single one.
Well, what happens with --enable-gmpcompat, at least on Windows, is
that two separate libraries are built: gmp and mpir. I guess the
former is as close to possible as plain gmp, without any features
added by mpir (in fact the gmp library is a little bit smaller). The
MPIR and GMP DLLs have no dependencies on each other.
I did a fresh build of Singular using the current unmodified spkg and
found that the Singular executable itself was linked with:
-lflint -lmpfr -lmpir -lm -lsingfac -lsingcf -lflint -lmpfr -lntl
-lgmp -lreadline -lpthread -lrt -lm -lomalloc
The repetitious stuff is annoying, but harmless. The harm here is
that there is both -lmpir and -lgmp. The -lmpir in this case comes
from Singular's configure.in where it's added to a variable called
FLINT_LIBS which is included in the linker flags for Singular and
libsingular. I don't know if there's some reason it absolutely must
link with mpir for flint to work, but I doubt it?
Further revealing is
$ dumpbin.exe /IMPORTS local/bin/Singular-3-1-7.exe
Dump of file local/bin/Singular-3-1-7.exe
File Type: EXECUTABLE IMAGE
Section contains the following imports:
cyggmp-16.dll
10091C158 Import Address Table
10091B0C8 Import Name Table
0 time date stamp
0 Index of first forwarder reference
DC __gmpn_get_str
195 __gmpz_addmul
196 __gmpz_addmul_ui
19C __gmpz_cdiv_q
19F __gmpz_cdiv_qr
1C1 __gmpz_fdiv_qr_ui
1E2 __gmpz_init_set_str
224 __gmpz_sqrt
228 __gmpz_submul
237 __gmpz_ui_pow_ui
cygmpir-16.dll
10091C1B0 Import Address Table
10091B120 Import Name Table
0 time date stamp
0 Index of first forwarder reference
45 __gmp_set_memory_functions
48 __gmp_sprintf
5A __gmpf_abs
5B __gmpf_add
...
I don't know exactly in what order the GNU linker is resolving symbols
on Windows, but as you can see it is only using 10 functions from the
GMP library, and the rest from MPIR--notably including
mp_set_memory_functions, which jibes with what I found in debugging.
Further revealing is that one of the few functions that are linked to
GMP is mpz_addmul. From my debugging it was exactly in an mpz_addmul
where the default memory allocator was used for an mpz_t, followed
later by an mpz_clear that used the omalloc free on the same object.
So details of the linker aside, this perfectly explains the behavior I
was seeing. It also explains why when I manually removed all
references to "-lgmp" from the Singular makefiles, I was able to fix
the problem.
Now all that needs to be done is the Singular package needs to be
patched properly to *only* use the appropriate $(MP_LIBRARY) (issues
with Sage's gmp package aside), and never get mixed up like this.
Best,
Erik
--
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.
