Hi,
I have compiled sage-5.5 from source on my ubuntu machine and the
following tests fail on running 'make ptestlong' -
sage -t --long -force_lib devel/sage/sage/interacts/debugger.py # Time
out
sage -t --long -force_lib devel/sage/sage/tests/startup.py # Time out
sage
On Dec 31, 5:35 pm, Robert Bradshaw
wrote:
> Yeah, sticking an untrack there certainly seems safe. It looks
> like PyObject_GC_UnTrack is idempotent, so we don't have to track it before
> going up the dealloc stack. If this fixes it, I sense another Cython
> release around the corner...
Not quite
On Mon, Dec 31, 2012 at 5:24 PM, Nils Bruin wrote:
> On Dec 31, 5:15 pm, Robert Bradshaw wrote:
> > Looking at this more, this seems fine, as the un-initialized members are
> > NULL before cinit completes, and set to null as dealloc progresses
> > using Py_CLEAR. The traversal and clear function
On Dec 31, 5:15 pm, Robert Bradshaw wrote:
> Looking at this more, this seems fine, as the un-initialized members are
> NULL before cinit completes, and set to null as dealloc progresses
> using Py_CLEAR. The traversal and clear functions ignore NULL members.
Except that the Py_CLEAR executions c
On Dec 31, 3:48 pm, Nils Bruin wrote:
> I bet there must be examples of this in the python library
> that show how to cooperate with superclasses that already want to
> control tracking/untracking.
It looks like the discussion in Objects/typeobject.c, line 1024
onwards might be of relevance.
--
On Dec 31, 3:23 pm, Robert Bradshaw
wrote:
> Curiously, we don't mark our objects as tracked or untracked in the
> constructor or destructor respectively in Cython at all. Hmm...
But the cinit and dealloc of object probably do support GC tracking,
so I suppose they get tracked and untracked from
On Mon, Dec 31, 2012 at 9:55 AM, Nils Bruin wrote:
> On Dec 31, 9:45 am, Simon King wrote:
> > > The difference between the "del A[1]" and "A.__delitem__(1)" might
> only be
> > > the fact that in the latter case (where more fucntions calls are
> performed)
> > > a gc is triggered whereas its no
On Dec 31, 10:38 am, Robert Bradshaw
wrote:
> Is there a build somewhere on sage.math that I could copy and reproduce
> this with?
There is now:
sage.math.washington.edu:/scratch/nbruin/5.6b2
I've inserted a gc.collect() into TripleDictEraser.__call__ to
reliably produce a crash with
./sage -t
A while back, I tried to compile on the Fedora distro for Raspberry Pi
and got similar messages. I was able to solve them by adding a swap file to
my system. The tiny amount of memory on the RasPi just can't seem to handle
it without a bit of help.
I also ran in to some other issues with AT
I just got my raspberry pi and thought that I would try to build this. It
crashes gcc.(not enough memory?)
Here is the log of what happened. I had been building it for about 2 days
before the crash.
mv -f .deps/ple.Tpo .deps/ple.Plo
/bin/bash ./libtool --tag=CC --mode=compile gcc -std=gnu99
On Mon, Dec 31, 2012 at 8:39 AM, Jean-Pierre Flori wrote:
>
>
> On Monday, December 31, 2012 5:32:05 PM UTC+1, Nils Bruin wrote:
>>
>> On Dec 31, 7:29 am, Nils Bruin wrote:
>>
>> > I am not sure that this is exactly the issue we're running into, but
>> > it seems plausible (it certainly needs a v
Is there a build somewhere on sage.math that I could copy and reproduce
this with?
On Mon, Dec 31, 2012 at 9:34 AM, Jean-Pierre Flori wrote:
>
>
> On Monday, December 31, 2012 5:50:40 PM UTC+1, Volker Braun wrote:
>>
>> If you want to increase the chance of a garbage collection to happen in
>> T
Sounds reasonable.
In this context, a container is an object with a tp_traverse handler. That
is, any object that can refer to another object and, therefore, be part of
a cyclic garbage collection.
For extension types on should use PyObject_GC_UnTrack and not the macro
version PyObject_GC_U
On Dec 31, 9:45 am, Simon King wrote:
> > The difference between the "del A[1]" and "A.__delitem__(1)" might only be
> > the fact that in the latter case (where more fucntions calls are performed)
> > a gc is triggered whereas its not in the first case, that's just a wild
> > guess though.
>
> Tha
On Monday, December 31, 2012 6:49:03 PM UTC+1, Jean-Pierre Flori wrote:
>
>
>
> On Monday, December 31, 2012 6:36:16 PM UTC+1, Nils Bruin wrote:
>>
>> On Dec 31, 8:46 am, Jean-Pierre Flori wrote:
>> > Of course, if Nils is right, it might not be up to us to solve such
>> > problems, but rather
On Monday, December 31, 2012 6:36:16 PM UTC+1, Nils Bruin wrote:
>
> On Dec 31, 8:46 am, Jean-Pierre Flori wrote:
> > Of course, if Nils is right, it might not be up to us to solve such
> > problems, but rather Python itself...
>
> It might by cython, not python:
>
> A little grepping in the
Hi Jean-Pierre,
On 2012-12-31, Jean-Pierre Flori wrote:
>> What you see is that during
>> our callback, a garbage collection is triggered! This of course
>> discovers all sorts of things that can be deleted, including things
>> that are already scheduled for deletion. Other interpretations wou
On Dec 31, 8:46 am, Jean-Pierre Flori wrote:
> Of course, if Nils is right, it might not be up to us to solve such
> problems, but rather Python itself...
It might by cython, not python:
A little grepping in the Python source shows that the first thing
dealloc methods do is call _PyObject_GC_UNT
On Monday, December 31, 2012 5:50:40 PM UTC+1, Volker Braun wrote:
>
> If you want to increase the chance of a garbage collection to happen in
> TripleDictEraser.__call__ then there is an obvious trick to do that. I've
> added the corresponding patch to #13864. With this, I get a crash in
> mo
If you want to increase the chance of a garbage collection to happen in
TripleDictEraser.__call__ then there is an obvious trick to do that. I've
added the corresponding patch to #13864. With this, I get a crash in
module.pyx every time.
http://trac.sagemath.org/sage_trac/attachment/ticket/1386
On Monday, December 31, 2012 5:39:26 PM UTC+1, Jean-Pierre Flori wrote:
>
>
>
> On Monday, December 31, 2012 5:32:05 PM UTC+1, Nils Bruin wrote:
>>
>> On Dec 31, 7:29 am, Nils Bruin wrote:
>>
>> > I am not sure that this is exactly the issue we're running into, but
>> > it seems plausible (it
On Monday, December 31, 2012 5:32:05 PM UTC+1, Nils Bruin wrote:
>
> On Dec 31, 7:29 am, Nils Bruin wrote:
>
> > I am not sure that this is exactly the issue we're running into, but
> > it seems plausible (it certainly needs a very brittle confluence of
> > circumstances to become apparent).
On Dec 31, 7:29 am, Nils Bruin wrote:
> I am not sure that this is exactly the issue we're running into, but
> it seems plausible (it certainly needs a very brittle confluence of
> circumstances to become apparent). Furthermore, I think it is a
> scenario that does need addressing, because Triple
On Monday, December 31, 2012 5:23:42 PM UTC+1, Jean-Pierre Flori wrote:
>
>
>
> On Monday, December 31, 2012 4:51:16 PM UTC+1, Jean-Pierre Flori wrote:
>>
>>
>>
>> On Monday, December 31, 2012 4:29:18 PM UTC+1, Nils Bruin wrote:
>>>
>>> On Dec 31, 12:58 am, Jean-Pierre Flori wrote:
>>> > But th
On Monday, December 31, 2012 4:51:16 PM UTC+1, Jean-Pierre Flori wrote:
>
>
>
> On Monday, December 31, 2012 4:29:18 PM UTC+1, Nils Bruin wrote:
>>
>> On Dec 31, 12:58 am, Jean-Pierre Flori wrote:
>> > But then I had a look at the C code Cython generated and thought it
>> was
>> > the same..
On Dec 31, 7:32 am, Simon King wrote:
> But I completely forgot: What exactly is the failing test, and what
> patches need to be applied to make it fail?
It's sage -t devel/sage/sage/modules/module.pyx on 5.6b0. However:
- I sometimes need to run it *twice* (I guess because some *.pyc
files must
On Monday, December 31, 2012 4:29:18 PM UTC+1, Nils Bruin wrote:
>
> On Dec 31, 12:58 am, Jean-Pierre Flori wrote:
> > But then I had a look at the C code Cython generated and thought it was
> > the same...
> > So we should look back at the C code, or ask a Python/Cython guru.
>
> The __del
On 12/27/12 12:39 PM, Jernej Azarija wrote:
Hello!
I apologize for posting this question here but somehow I am not allowed
to drop questions to sage-support. Moreover I do not feel confident
enough to post this thing as a bug on the trac wiki.
Working with a large graph G on ~250 vertices I hav
Hi Nils,
On 2012-12-30, Nils Bruin wrote:
> OK, caught redhanded.
Great!
But I completely forgot: What exactly is the failing test, and what
patches need to be applied to make it fail?
Or is there a new trac ticket on which I can find that information?
Best regards,
Simon
--
You received th
On Dec 31, 12:58 am, Jean-Pierre Flori wrote:
> But then I had a look at the C code Cython generated and thought it was
> the same...
> So we should look back at the C code, or ask a Python/Cython guru.
The __delitem__ compiles as an ordinary method lookup and call,
whereas the "del A[..]" compi
On Monday, December 31, 2012 4:09:47 PM UTC+1, Jean-Pierre Flori wrote:
>
>
>
> On Monday, December 31, 2012 12:12:52 AM UTC+1, Nils Bruin wrote:
>>
>> OK, caught redhanded. Indeed, the freelist of this pool ends up being
>> circular, due to a double free happening. The first free is
>> indeed
On Monday, December 31, 2012 12:12:52 AM UTC+1, Nils Bruin wrote:
>
> OK, caught redhanded. Indeed, the freelist of this pool ends up being
> circular, due to a double free happening. The first free is
> indeed coming from a TripleDictEraser callback. The second one doesn't
> seem to be. Indee
On Monday, December 31, 2012 7:59:21 AM UTC+1, Nils Bruin wrote:
>
> On Dec 24, 4:44 pm, Jean-Pierre Flori wrote:
>
> > Any reason for calling directly _refcache.__delitem__ rather than del
> > _refcache ?
> > Changing this solves the problem, but surely only by hiding the bug...
>
> I'm not
On Monday, December 31, 2012 11:41:32 AM UTC+1, Jean-Pierre Flori wrote:
>
>
>
> On Monday, December 31, 2012 11:33:25 AM UTC+1, Volker Braun wrote:
>>
>> If you want to use an external memory checker (like glibc MALLOC_CHECK_,
>> electric fence, or valgrind) you still have to use SAGE_VALGRIND
Hi,
it compiles well, except for conversion.c in libm4rie, which does
compile, but needs too much ram.
It passes all but three doctests (the gamma-related ones...).
I made a bdist available in the bdist/ directory of my home directory on
sage.math.washington.edu.
It's a little early but st
On Monday, December 31, 2012 11:33:25 AM UTC+1, Volker Braun wrote:
>
> If you want to use an external memory checker (like glibc MALLOC_CHECK_,
> electric fence, or valgrind) you still have to use SAGE_VALGRIND or python
> will use pymalloc. The latter has its own debugging code but is not
>
If you want to use an external memory checker (like glibc MALLOC_CHECK_,
electric fence, or valgrind) you still have to use SAGE_VALGRIND or python
will use pymalloc. The latter has its own debugging code but is not
transparent to external tools.
export SAGE_VALGRIND=yes
export SAGE_DEBUG=yes
On Sunday, December 30, 2012 5:40:05 PM UTC+1, Jean-Pierre Flori wrote:
>
>
> I had good hopes that with a --without-pymalloc build, we'd catch a
>> double free like this red handed, but no such luck (I cannot reproduce
>> the problem at all on debug builds).
>
> Me neither, too bad.
> At least
Does it work if you set
CFLAGS="-DOS_OBJECT_USE_OBJC=0"
export CFLAGS
make
On Sunday, December 30, 2012 6:11:14 PM UTC, Robert Zeier wrote:
>
> I am trying to build sage 5.6.beta1 from source,
> but mercurial does not build. (The same problem
> also applies to sage 5.5) Xcode 4.5.2 is install
On 2012-12-31 01:57, Timo wrote:
> I use the "incremental" filename feature a lot when I experiment with
> pictures: I like to see what I have plotted, in *chronological order*,
> using my image viewer. With the new random file names this is impossible.
If non-random names is what you want, then si
Your image viewer can probably list the thumbnails in chronological order.
If it can not you should get a better one. gThumb is nice on *nix.
Slightly related, "ls -t" lists files in chronological order.
Having predictable temp file names is bad for various reasons. Even if you
don't care abou
On 12/31/2012 08:57 AM, Timo wrote:
Hi,
Before 5.4, tmp_filename() would return "incremental" file names:
|
sage:tmp_filename()
'/home/jaje/.sage//temp/ukko/26221//tmp_0'
sage:tmp_filename()
'/home/jaje/.sage//temp/ukko/26221//tmp_1'
sage:tmp_filename()
'/home/jaje/.sage//temp/ukko/26221//tmp_2'
On Monday, December 31, 2012 7:59:21 AM UTC+1, Nils Bruin wrote:
>
> On Dec 24, 4:44 pm, Jean-Pierre Flori wrote:
>
> > Any reason for calling directly _refcache.__delitem__ rather than del
> > _refcache ?
> > Changing this solves the problem, but surely only by hiding the bug...
>
> I'm not
43 matches
Mail list logo
