On Oct 25, 9:34 pm, Robert Bradshaw <[EMAIL PROTECTED]>
wrote:
> On Oct 25, 2007, at 12:14 PM, mabshoff wrote:
>
> > On Oct 25, 8:04 pm, Robert Bradshaw <[EMAIL PROTECTED]>
> > wrote:
> >> On Oct 25, 2007, at 10:03 AM, mabshoff wrote:
>
> >>> On Oct 25, 11:25 am, mabshoff
> >>> <[EMAIL PROTECTED]
> >>> dortmund.de> wrote:
> >>>> On Oct 25, 9:06 am, Robert Bradshaw <[EMAIL PROTECTED]>
> >> Did you apply the accompanying .hg patch to sage-main?
>
> > nope, but that fixed the problem. It didn't seem obvious, so I ignored
> > that bundle.
>
> There's often a few tweaks that need to be done to the SAGE codebase
> to get it to work with the new cython...that one there was fixing a
> hack that didn't work anymore.
>
>
>
> > With the old Cython:
>
> > ==26784== LEAK SUMMARY:
> > ==26784== definitely lost: 0 bytes in 0 blocks.
> > ==26784== possibly lost: 251,078 bytes in 625 blocks.
> > ==26784== still reachable: 36,000,918 bytes in 20,368 blocks.
> > ==26784== suppressed: 0 bytes in 0 blocks.
>
> > With the new Cython and n=1 I get:
>
> > ==31741== LEAK SUMMARY:
> > ==31741== definitely lost: 0 bytes in 0 blocks.
> > ==31741== possibly lost: 253,574 bytes in 633 blocks.
> > ==31741== still reachable: 36,244,988 bytes in 20,359 blocks.
> > ==31741== suppressed: 0 bytes in 0 blocks.
>
> > So there has been a slight decrease in the number of blocks that are
> > still reachable or possibly lost, even thought the amount of memory
> > increased.
>
> More stuff is interned with the new cython (e.g. python int constants
> are pre-computed rather than constructed/destructed on the fly
> throughout the code) as well as other changes. I'm curious how n=0
> vs. n=1 behaves, as well as, of course, n=2+.
>
> > I will try with n=2 to see if anything changes. How do I
> > change the default by the way?
Hi Robert,
>
> Try adding "--clean 2" to line 1008 of process_cython_file() in
> setup.py.
>
that doesn't work yet, because the parsing of the command line doesn't
seem to comprehend --clean yet, so I hardcoded the value I wanted for
now.
With n=2 I get the following which might be the cause for the memory
corruption:
==14064== Invalid free() / delete / delete[]
==14064== at 0x4A1B74A: free (vg_replace_malloc.c:320)
==14064== by 0xB98B0D8:
__pyx_f_4sage_5rings_7integer_fast_tp_dealloc (integer.c:13607)
==14064== by 0x4B0022: collect (gcmodule.c:714)
==14064== by 0x4B0373: PyGC_Collect (gcmodule.c:1265)
==14064== by 0x4A612C: Py_Finalize (pythonrun.c:387)
==14064== by 0x4A5C7A: handle_system_exit (pythonrun.c:1616)
==14064== by 0x4A5E78: PyErr_PrintEx (pythonrun.c:1062)
==14064== by 0x4A6686: PyRun_SimpleFileExFlags (pythonrun.c:976)
==14064== by 0x412319: Py_Main (main.c:134)
==14064== by 0x4FD94C9: (below main) (in /lib/libc-2.3.6.so)
==14064== Address 0x73287d8 is 0 bytes inside a block of size 8
free'd
==14064== at 0x4A1B74A: free (vg_replace_malloc.c:320)
==14064== by 0xB98B0D8:
__pyx_f_4sage_5rings_7integer_fast_tp_dealloc (integer.c:13607)
==14064== by 0xB9847E2: cleanup (integer.c:15198)
==14064== by 0x415522: PyObject_Call (abstract.c:1860)
==14064== by 0x481ACA: PyEval_EvalFrameEx (ceval.c:3844)
==14064== by 0x484F3A: PyEval_EvalCodeEx (ceval.c:2831)
==14064== by 0x4CE527: function_call (funcobject.c:517)
==14064== by 0x415522: PyObject_Call (abstract.c:1860)
==14064== by 0x47C850: PyEval_CallObjectWithKeywords (ceval.c:3433)
==14064== by 0x4A60BC: Py_Finalize (pythonrun.c:1589)
==14064== by 0x4A5C7A: handle_system_exit (pythonrun.c:1616)
==14064== by 0x4A5E78: PyErr_PrintEx (pythonrun.c:1062)
> - Robert
Carl Witty was also wondering whether your new Cython.spkg was ready
for 2.8.10 or if we should wait.
Cheers,
Michael
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to sage-devel@googlegroups.com
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://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/
-~----------~----~----~----~------~----~------~--~---
