On Oct 29, 10:03 pm, Jaap Spies <[EMAIL PROTECTED]> wrote:
> Hi Machael,
>
Hi Jaap,
>
>
> You wrote:
>
> > On Oct 29, 9:18 pm, Jaap Spies <[EMAIL PROTECTED]> wrote:
> >> Michael,
>
> > Hello Jaap,
>
> >> Remembering that dance(10) has a segmentation fault long before
> >> there was a function _choose, is it possible that some other
> >> part of the code is going wild?
>
> > Sure, but so far no lead. Which specific version did exhibit that
> > behavior? I can build older releases locally and see if I can come up
> > with anything.
>
> On 23 Oct I wrote:
>
> To day I got with sage-2.8.8.1:
>
Well, I just looked at the patch where you introduced _choose and the
lst you create is indentical.
> > > sage: time dance(10)
> > >
> > >
> > > ------------------------------------------------------------
> > > Unhandled SIGSEGV: A segmentation fault occured in SAGE.
> > > This probably occured because a *compiled* component
> > > of SAGE has a bug in it (typically accessing invalid memory)
> > > or is not properly wrapped with _sig_on, _sig_off.
> > > You might want to run SAGE under gdb with 'sage -gdb' to debug this.
> > > SAGE will now terminate (sorry).
> > > ------------------------------------------------------------
>
> > Now that 2.8.10 with all your speed improvements is out I will do some
> > more testing with that release on sage.math with a 32 bit binary to
> > see if I can flush anything out with that.
>
> Warning: see the reopened trac #217, I stupid changed some Py_ssize_t
> in ints, but knowing the nrows and ncols are small, there will be no
> problem, I hope!
>
Nope, I understand the argument to change it back, but the change
shouldn't case any trouble.
> > As I wrote above: The issues with the refcount going insane is a nice
> > result from the debugging and that will hopefully lead to some
> > improvements in our fight against memleaks.
>
> Thanks and good luck,
Carl had some interesting input:
[02:03] <cwitty> I was looking at those refcounts some more.
[02:03] <mabshoff> ok
[02:03] <cwitty> It turns out that Python caches and shares small int
objects:
[02:04] <cwitty> sage: a = int(0)
[02:04] <cwitty> sage: sys.getrefcount(a)
[02:04] <cwitty> 6288
[02:04] <cwitty> sage: b = int(0)
[02:04] <cwitty> sage: sys.getrefcount(a)
[02:04] <cwitty> 6289
[02:04] <cwitty> sage: a is b
[02:04] <cwitty> True
[02:04] <mabshoff> ok
[02:04] <cwitty> So the reference-counting problem could be anywhere
that deals with small Python ints.
[02:05] <mabshoff> mmmh.
[02:05] <mabshoff> So it is not the list [0], but the smallint 0 that
has the reference counter overflow?
[02:06] <cwitty> Let me go look at your printouts again. I thought
so, but I didn't look closely.
[02:06] <cwitty> Yeah, that's what it looks like to me. (Just judging
from your next-to-latest e-mail.)
[02:07] <mabshoff> Because the numbers "jump", while I would expect
them to increase by 1 each time.
[02:11] <cwitty> So it looks like between your first and second
printouts, the refcount for "0" jumped by 135, and the refcount for
"1" jumped by at least 125 (to make it wrap).
[02:11] <mabshoff> Yep, otherwise it would take *forever* to even wrap
on a 32 bit box.
So now comes the question: Why doesn't the refcount get decremented?
How do we fix this?
>
> Jaap
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/
-~----------~----~----~----~------~----~------~--~---
