#5344: [with patch, needs review] Singular/omalloc "double free" problem
-------------------------+--------------------------------------------------
Reporter: GeorgSWeber | Owner: mabshoff
Type: defect | Status: new
Priority: blocker | Milestone: sage-3.4
Component: packages | Keywords:
-------------------------+--------------------------------------------------
Singular/omalloc relies on and incorporates as "default malloc" a certain
adapted version of dlmalloc version 2.6.5 from 1998.
Let's explicitly choose this very dlmalloc code to be an "external malloc"
for Singular/omalloc, by taking the current
"singular-3-0-4-4-20080711.p3.spkg" and adding to its spkg-install in its
"config()" subscript the three lines:
{{{
--with-malloc=external \
--with-external-malloc-h=dlmalloc.h \
--with-external-malloc-c=dlmalloc.c \
}}}
Compiling and installing the thus adapted spkg results in a omalloc
library which is almost identical (up to possibly some redefinition
of "strdup").
This is due to the fact that the omalloc "configure" run produces
essentially the same output, with only one exception: it now chooses to
define the macro "OMALLOC_USES_MALLOC", which by default is not the case.
"Inside" omalloc, the differences are marginal.
But in the Singular code itself, there are three files where code depends
on the presence of this macro "OMALLOC_USES_MALLOC". This leads to
differences, although the underlying omalloc binaries are virtually the
same (the "strdup" issue hardly interferes).
Now from the Sage point of view, the difference is more than annoying,
since on a Mac OS X system suddenly:
{{{
sage: EllipticCurve(GF(17),[0,1,1,10,13])
Elliptic Curve defined by y^2 + y = x^3 + x^2 + 10*x + 13 over Finite
Field of size 17
sage: exit
Exiting SAGE (CPU time 0m0.14s, Wall time 0m34.71s).
sage.bin(20597) malloc: *** Deallocation of a pointer not malloced:
0x7e75018; This could be a double free(), or free() called with the middle
of an allocated block; Try setting environment variable MallocHelp to see
tools to help debug
sage.bin(20597) malloc: *** Deallocation of a pointer not malloced:
0x7e75020; This could be a double free(), or free() called with the middle
of an allocated block; Try setting environment variable MallocHelp to see
tools to help debug
sage.bin(20597) malloc: *** Deallocation of a pointer not malloced:
0x7e73078; This could be a double free(), or free() called with the middle
of an allocated block; Try setting environment variable MallocHelp to see
tools to help debug
sage.bin(20597) malloc: *** Deallocation of a pointer not malloced:
0x7e73068; This could be a double free(), or free() called with the middle
of an allocated block; Try setting environment variable MallocHelp to see
tools to help debug
}}}
we run into a "double free" problem at exiting sage, whenever code is
called that relies somehow on Singular.
Since the macro "OMALLOC_USES_MALLOC" is essentially the only thing that
changed, and there are only less than a handful places in the Singular
code where it is evaluated, a search by hand and trial-and-error resulted
in the files "kernel/mminit.cc" resp.
"kernel/mmstd.c" being the culprits.
Now the omalloc submodule could be patched ("configure" and
"configure.in") so that the macro "OMALLOC_USES_MALLOC" is not set at all.
But from the test case at hand is to be deduced that the
"OMALLOC_USES_MALLOC" code branch in "kernel/mminit.cc" as such is not
trustworthy, so patching the omalloc submodule would only cover the bug,
far away from its source.
Looking at the code in "kernel/mminit.cc", why the heck suddenly these
"double frees" should occur?
Maybe it's trivially somewhere the "wrong" free() being called (instead of
the one implicitly set by "mp_set_memory_functions()")?
Looking at the file "kernel/mmstd.c", especially given that exactly for
"ix86_Win", "ppcMac_darwin", and "ix86Mac_darwin" (see lines 13 - 20) the
function freeSize() is defined using unconditionally the
"system" free(), there is quite some plausibility for this.
(Could somebody upstream that question to the Singular dev team?)
Anyway, for now, one cannot trust any further that alternate code path,
which in "default" Singular is the one *not* being compiled in.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/5344>
Sage <http://sagemath.org/>
Sage - Open Source Mathematical Software: Building the Car Instead of
Reinventing the Wheel
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en
-~----------~----~----~----~------~----~------~--~---
