On Feb 23, 12:44 am, "Georg S. Weber" <georgswe...@googlemail.com>
wrote:
> On 23 Feb., 08:10, mabshoff <mabsh...@googlemail.com> wrote:
Hi Georg,
>
> We definitely *are* closing in on this devious bunch of bugs. I had
> touched four Cython files (the ones noted in that other recent
> Singular thread) and then did "sage -b" quite many times the past
> weekend during experimenting around, but admittedly I didn't do a full
> rebuild from scratch.
Well, I have a patch that makes the libSingular extensions depend on a
Singular headers, so a -b rebuilds them automatically if I rebuild the
singular.spkg. Since I need to do that quite often I will get that
trivial patch into 3.4.
> I'll do that as soon as I can, but I fear that the outcome will be too
> late for Sage 3.4. Anyway, there is more than one way we could proceed
> on --- one of them will lead us to our goal.
Absolutely.
> Probably there is more than one issue interwoven (I saw that David
> Harvey once fixed a Sage ticket related to the Singular/omalloc
> redefiniton of "strdup", which might hurt us here again), but that
> certainly can and will be sorted out.
Do you have that ticket number handy?
> Cheers,
> gsw
Re the comments you just made on #5344: You propose to use
--with-malloc=external \
--with-external-malloc-h=dlmalloc.h \
--with-external-malloc-c=dlmalloc.c \
I *thought* that is equivalent to --with-malloc=system, but I might be
wrong. Since I use that in 64 bit mode on OSX (as well as the Cygwin
build, but that might not be needed there) and it introduces the exact
same failures I did rebuild the libSingular extensions after building
the singular.spkg in 64 bit mode using the system malloc. You patch
from #5344 does indeed make the two double free issues I observed go
away.
My initial thought was that the problems were with the Rational dtor
of Givaro ending up calling the dtor of Singular's Rational class, but
now I am starting to believe that this was caused by the mixup between
the two free implementations that you pointed out and fixed. That does
actually make a whole lot more sense since my earlier theory seemed
very strange. I come to the likely erroneous conclusion after
modifying Singular's Rational dtor to not free anything and that made
the problem go away, but it did not fix the underlying bug :(.
Now to answer your questions from the ticket:
1. Under which circumstances does this "minpoly issue" occur? Please
give me a kind of recipe.
Just build Singular.spkg with --with-malloc=system. I do believe that
is equivalent to the above solution you gave, but I am in the process
of verifying that. If it is not we might be able to get rid of the --
with-malloc=system for 64 bit OSX (and maybe Cygwin, too?) and fix
this issue at the same time.
The minpoly issue makes several doctests crash - see the list at
http://wiki.sagemath.org/osx64/sage-3.3
Notes:
* While 25 or so doctests failed on OSX 64 bit well over 900 passed
while every time at exit Sage did cause double frees, so a passing
test suite is no indication that the minpoly problem went away. The
crashing doctests where I wrote something about being libSingular
related were cases where dozens if not hundreds of double free
problems occurred right before segfaulting the Sage doctest run *way
before* it was finished, so this is not a cleanup at exit problem. I
also suspected that this might be an issue where an extension linked
against omalloc, but not libSingular, but any extension linking
against omalloc also links against libSingular, so all of those were
rebuild and a build from scratch is unlikely to fix this issue.
* The "double free at exit" issue patch you posted will probably fix
some of those failing doctest mentioned on the osx64 bit wiki page,
but I still did hit double free issues while doctesting Sage as
mentioned above, not at exit. I did hit one very quickly when testing
with my Sage 3.3. 64 bit OSX build, but after your patch they might
just harder to hit, i.e. all your long tests passed on your 32 bit OSX
10.4 build, but I had those failure in the log. I also believe that if
you build "your" singular.spkg on Linux you will see some issues under
valgrind, but if your fix is not equivalent to my use of --with-
malloc=system this patch might still solve all our problems. I will
know more in a couple hours. Due to the way the doctesting framework
works you will not see any of the double free messages unless you have
a failure or a segfault, so this is why I am hesitant to call the
minpoly issue fixed until I have substantial evidence via building +
valgrind that it truly goes away. You might have just gotten lucky
that none of the tests segfaulted.
* Since we hit the same issue at Dev1 only once I think this is just
an incredibly hard to hit bug and back then it was next to impossible
to reproduce it, i.e only one binary build on sage.math showed the
problem and we could not reproduce the problem by rebuilding seemingly
the exact same Sage release using the same compiler, etc. But now I
can reproduce this reliably over several Sage releases *every* time we
build using the system malloc on OSX in 32 and 64 bit, so I believe
this is a real bug and we will now fix it.
2. Under which circumstances, in contrast, does the "minpoly issue" go
away? Again, please give me a list of what to be done/seen.
It goes away even for 32 bit OSX build of Sage when I switch to not
using the system malloc and rebuilding the extensions depending on
libSingular. The double frees are there also when just using system
malloc (this is without your patch to the Singular.spkg in both cases,
but I will test that shortly with a 3.3 32 bit build). This is all on
OSX 10.5, so this might be a contributing factor since you test on OSX
10.4 AFAIK. If you want to reproduce this just take the same setup as
64 bit OSX from Singular's spkg-install and make it use the same
config modulo the compile flags in 32 bit OSX.
Keep up the great work, this has been an *incredible* amount of
debugging-fu and I am glad you are a Sage developer :)
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
To unsubscribe from this group, send email to
sage-devel-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sage-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
