On Feb 22, 10:01 pm, "Georg S. Weber" <[email protected]>
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
--~--~---------~--~----~------------~-------~--~----~
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-devel
URLs: http://www.sagemath.org
-~----------~----~----~----~------~----~------~--~---
