On 23 Feb., 08:10, mabshoff <mabsh...@googlemail.com> wrote:
> On Feb 22, 10:01 pm, "Georg S. Weber" <georgswe...@googlemail.com>
> wrote:
>
> > C'mon,
>
> Hi Georg,
>
> > this does need a very thorough doctesting on as many architectures as
> > possible! My own overnight run with Sage 3.3 with additionally #5344
> > and #4181 applied has finished:
> > {{{
> > ----------------------------------------------------------------------
> > All tests passed!
> > Total time for all tests: 9321.6 seconds}}}
>
> > That's the result of "MAKE testlong" on my MacBook Core2Duo, with Mac
> > OS X 10.4.11 and Xcode 2.5
> > (with MAKE='make -j2'). So for the first time ever, *all* the long
> > doctests for some Sage version did succeed on this box.
>
> > I'll have a look at the ticket descriptions in a minute, hopefully I
> > didn't foul things up (yeah, hope dies last ...).
>
> Unfortunately your patch only fixes two of the three problems that pop
> up when switching Singular to use the system's malloc, i.e. the
> minpoly problem I mention on the ticket still occurs. I did a build
> from scratch over night after patching your changes into the
> Singular.spkg+rebuild of the libSingular based extensions failed some
> doctests involving minpoly and I will test the new build today to make
> 100% it wasn't something in my build, but I don't have any realistic
> hope this will be fixed by a build from scratch.
>
> Note that those pesky invalid/double frees on OSX only pop up from
> doctesting on the screen only *if* the doctest segfaults or fails some
> other way, so passing doctests for you on OSX are unfortunately no
> indicator that this code works for the minpoly problem. And since I
> saw those failures on OSX in 32 bit mode I am sure they are still
> there. This code also needs to go through a complete round of
> valgrinding anyway since it needs to be verified that no leaks are
> introduced. I think the fix you made is a tremendous achievement and
> should definitely be pushed upstream, but alas the minpoly problem
> still makes it a "needs work", especially in light of the fact that we
> need a stable Sage 3.4 for SD 13 and known bugs are better than
> potentially new unknown bugs :).
>
> The minpoly problem was first observed at Dev1 when the coercion
> branch was merged into Sage and we did a test build on sage.math. It
> was only observable on one such build, so there is some definite
> strangeness going on and back then we failed to find the root cause
> and fix it. Since it "went away" when we merged some of new coercion
> piece by piece we eventually closed the ticket as fixed since the
> issues in question (an invalid read in libSingular that was
> "impossible" since it got past a ring check) was gone. It would be
> very helpful if a Cython expert could look at the generated code and
> figure out what is going on for minpoly since that fix would allow us
> to merge your two fixes.
>
> > Cheers,
> > gsw
>
> Cheers,
>
> Michael
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.
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.
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.
Cheers,
gsw
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
