On Thu, Aug 12, 2010 at 3:01 PM, Mitesh Patel <qed...@gmail.com> wrote: > On 08/11/2010 07:19 PM, Robert Bradshaw wrote: >> On Wed, Aug 11, 2010 at 4:15 PM, Mitesh Patel <qed...@gmail.com> wrote: >>> On 08/11/2010 03:25 AM, Mitesh Patel wrote: >>>> On 08/05/2010 11:12 PM, Robert Bradshaw wrote: >>>>> On Thu, Aug 5, 2010 at 4:26 AM, Mitesh Patel <qed...@gmail.com> wrote: >>>>>> On 08/04/2010 03:10 AM, Robert Bradshaw wrote: >>>>>>> So it looks like you're getting segfaults all over the place as >>>>>>> well... Hmm... Could you test with >>>>>>> https://sage.math.washington.edu:8091/hudson/job/sage-build/163/artifact/cython-devel.spkg >>>>>>> ? >>>>>> >>>>>> With the new package, I get similar results, i.e., apparently random >>>>>> segfaults. The core score is about the same: >>>>> >>>>> Well, it's clear there's something going on. What about testing on a >>>>> plain-vanilla sage (with the old Cython)? >>>> >>>> I get similar results on sage.math with the released 4.5.3.alpha0: >>>> >>>> $ cd /scratch/mpatel/tmp/cython/sage-4.5.3.alpha0-segs >>>> $ find -name core_x\* -type f | wc >>>> 30 30 1315 >>>> $ grep egmentation ptestlong-j20-*log | wc >>>> 11 70 939 >>>> >>>> So the problem could indeed lie elsewhere, e.g., in the doctesting system. >>>> >>>> I'll try to run some experiments with the attached make-based parallel >>>> doctester. >>> >>> With the alternate tester and vanilla 4.5.3.alpha0, I get "only" the 20 >>> cores in >>> >>> data/extcode/genus2reduction/ >>> >>> (I don't know yet how many times and with which file(s) this fault >>> happens during each long doctest run nor whether certain files >>> reproducibly trigger the fault.) > > > I made 20 copies of 4.5.3.alpha0. In each copy, I ran the long doctest > suite serially with the alternate tester, which I modified to rename any > new cores after each test. All copies end up with a "stealth" core in > > data/extcode/genus2reduction/ > > and point to > > sage/interfaces/genus2reduction.py > > as the only source of this core. I'll open a ticket. > > >>> Moreover, the only failed doctests are in startup.py (19 times) and >>> decorate.py (once). The logs maketestlong-j20-* don't explicitly >>> mention segmentation faults. >>> >>> So sage-ptest may be responsible, somehow, for the faults that leave >>> cores in apparently random directories and perhaps also for random test >>> failures. > > > Here's one problem: When we test > > /path/to/foo.py > > sage-doctest writes > > SAGE_TESTDIR/.doctest_foo.py > > runs the new file through 'python', and deletes it. This can cause > collisions when we test in parallel multiple files with the same > basename, e.g., __init__, all, misc, conf, constructor, morphism, index, > tests, homset, element, twist, tutorial, sagetex, crystals, > cartesian_product, template, ring, etc. (There's a similar problem with > testing non-library files, which sage-doctest first effectively copies > to SAGE_TESTDIR.) We could instead use > > .doctest_path_to_foo.py > > or > > .doctest_path_to_foo_ABC123.py > > where ABC123 is unique. With the latter we could run multiple > simultaneous tests of the same file. I'll open a ticket or maybe use an > existing one.
Could we use the tempfile module instead of using SAGE_TESTDIR. The tempfile module makes files and directories by default that are unique and are *designed* to live on a fast filesystem, which gets cleaned regularly. sage: import tempfile William -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
