On Sun, Mar 29, 2009 at 12:38 AM, Peter Jeremy <peterjer...@optushome.com.au> wrote: > On 2009-Mar-28 21:12:09 -0700, mabshoff <mabsh...@googlemail.com> wrote: >>On Mar 28, 9:08 pm, Peter Jeremy <peterjer...@optushome.com.au> wrote: >>> On 2009-Mar-28 20:00:12 -0700, William Stein <wst...@gmail.com> wrote: >>> >On Sat, Mar 28, 2009 at 7:55 PM, Peter Jeremy >>> ><peterjer...@optushome.com.au> wrote: >>> >> sage -t "devel/sage/sage/schemes/elliptic_curves/lseries_ell.py" >>> >> Runs out of swap. >>> >How much RAM does this machine have? How much swap does this machine have? >>> 2GB RAM, 9GB swap. >> >>Strange. Can you run the test with -verbose and determine which test >>is going off to eat all the RAM+Swap? > > ... > Trying: > L(Integer(2))###line 103:_sage_ >>> L(2) > Expecting: > 0.381575408260711 > ok > Trying: > e = > EllipticCurve([Integer(1),Integer(1),Integer(0),-Integer(63900),-Integer(1964465932632)])###line > 112:_sage_ >>> e = EllipticCurve([1,1,0,-63900,-1964465932632]) > Expecting nothing > ok > Trying: > L = e.lseries().dokchitser(Integer(15))###line 113:_sage_ >>> L = > e.lseries().dokchitser(15) > Expecting: > Traceback (most recent call last): > ... > RuntimeError: Unable to create L-series, due to precision or other limits > in PARI. > *** *** Error: TIMED OUT! PROCESS KILLED! *** *** > *** *** Error: TIMED OUT! *** *** > [362.9 s] > exit code: 1024 > > There was a 'gp' process that sat thrashing at 2.5GB for a while then > doubled in size to 4.9GB and again doubled to 9.7GB before the parent > timed out and exited - it did not kill the gp process. Interestingly, > it reported the runtime error quite early on and kept going.
That's *definitely* a bug in your Sage build. gp doubles its stack when it gets an error that indicates it runs out of memory. Something must be triggering that error. It seems like we need a common FreeBSD server somewhere to develop on together in order to resolve these issues. Please contact Tom Boothby (<boot...@u.washington.edu>) who will make you an account on the sage.math devel cluster; I have freebsd 32 and 64-bit (virtual) servers there and can make you an admin on them. I hope you'll use ulimit when doctesting :-) > I repeated the test with ulimit -v set to 2048000 (ie about 2GB) and > the test "succeeded": > ... > Trying: > L(Integer(2))###line 103:_sage_ >>> L(2) > Expecting: > 0.381575408260711 > ok > Trying: > e = > EllipticCurve([Integer(1),Integer(1),Integer(0),-Integer(63900),-Integer(1964465932632)])###line > 112:_sage_ >>> e = EllipticCurve([1,1,0,-63900,-1964465932632]) > Expecting nothing > ok > Trying: > L = e.lseries().dokchitser(Integer(15))###line 113:_sage_ >>> L = > e.lseries().dokchitser(15) > Expecting: > Traceback (most recent call last): > ... > RuntimeError: Unable to create L-series, due to precision or other limits > in PARI. > ok > Trying: > set_random_seed(0L) > Expecting nothing > ok > ... > > It looks like this test just falls foul of FreeBSD/amd64's process size > limits (though whatever reports the RuntimeError should stop and not > continue at that point). > >>I also looked at http://wiki.sagemath.org/freebsd/sage-3.4 and I am >>dubious about some of the patches, especially about most of the bits >>from ports. > > There are only 3 sets of patches that come out of FreeBSD ports. > Of these, only the python fixes may be unnecessary. > > gap: These patches were necessary to make gap compile. Note that > posix_openpt() is the recommended way of accessing PTYs since FreeBSD > 5.x and, following the re-write of the TTY subsystem in 8.x, the old > BSD PTYs no longer exist by default. > > matplotlib: The change from to_int() to to_float() comes from FreeBSD > but is needed to avoid the > ValueError: invalid literal for int() with base 10: '539.621' > that I initially reported. > > python: These patches are almost all straight from FreeBSD. They > probably are overkill (though python internally has code to support > FreeBSD only up to 6.x, so there may be some parts that are needed for > 7.x and 8.x). (My initial suspicion was that the above problem was > python so I patched it. When that didn't help, I went digging deeper > but did not pull out the python fixes). > >>fixes are pushed upstream. The choice of using shar as an archive >>format also seems rather strange to me. > > I had hoped that Moin would allow them to be directly viewed - but > it doesn't so I might switch back to using tar. > >>Which java are you using? > > java version "1.5.0_14-p8" > > On 2009-Mar-28 21:38:09 -0700, mabshoff <mabsh...@googlemail.com> wrote: >>Yep, we discussed this over lunch. When I was doctesting with FreeBSD >>7 and the SunJDK that ran via the linux emulation layer things went >>pretty badly. > > Looking at atimes, something did use java whilst the tests were > running and I don't think anything else would have. > >>Re putchar(): I have this patch for gcc 4.3 on Solaris in tree: >> >>--- pprdrv_tt2.cpp.orig 2009-01-19 06:37:37.373517000 -0500 >>+++ pprdrv_tt2.cpp 2009-01-19 06:38:26.782530000 -0500 >>@@ -104,7 +104,8 @@ >> { /* have a log of points. */ >> if(stack_depth == 0) >> { >>- stream.putchar('{'); >>+ // Note the below is a hack to make it compile on >>Solaris 10 with gcc 4.3.2 >>+ stream.puts("{"); >> stack_depth=1; >> } >> >>It will likely fix the issue you are seeing on FreeBSD 8 + gcc 4.3, >>too. > > In my case, it was the declaration that blew up first: > building 'matplotlib.ttconv' extension > creating build/temp.freebsd-8.0-CURRENT-amd64-2.5/ttconv > gcc -fno-strict-aliasing -DNDEBUG -D__wchar_t=wchar_t -fPIC > -I/home/peter/sage/sage-3.4/local/include -I/usr/local/include -I/usr/include > -I. -I/home/peter/sage/sage-3.4/local/include/ > -I/home/peter/sage/sage-3.4/local/include/python2.5 -c src/_ttconv.cpp -o > build/temp.freebsd-8.0-CURRENT-amd64-2.5/src/_ttconv.o > In file included from src/_ttconv.cpp:8: > ./ttconv/pprdrv.h:43: error: expected unqualified-id before '!' token > ./ttconv/pprdrv.h:43: error: expected `)' before '!' token > error: command 'gcc' failed with exit status 1 > >> * you are patching files like configure scripts and you really should >>not do that :) > > IMO, GNU configure is a massive impediment to portability. I agree I > shouldn't be patching the configure scripts - and if GNU configure > worked as advertised, I wouldn't need to. Where it's only a simple > fix, it's easier to hack the configure script than work out where the > input files are broken and then re-run autoconf. > >> * most of the fixes should be pushed upstream > > Agreed. I've already pushed the libm4ri fix upstream (and it has been > accepted). I will work through the other fixes and feed the upstream > if appropriate. > >>I think the first step would be to provide individual patches so that >>we can decide what to integrate and what to leave out. > > I intend to submit each patch to trac as soon as I have an account. > >> Some of the >>fixes should certainly go in while I cam quite dubious about others, >>but we can do that on a case by case review. > > I'm not sure that what I've done is necessarily either the best or > even most correct approach and see it as a work-in-progress. I > was initially using the base gcc4.2 and installed g95 but ran into > problems and switches to the gcc4.3 toolchain. As a result, some > of my earlier patches may not be relevant any longer. > > I will try a FreeBSD-7.1/amd64 environment if I have time during > the week. > > -- > Peter Jeremy > -- William Stein Associate Professor of Mathematics University of Washington http://wstein.org --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
