Access violation when no memory

[Phil Mayes]

Pat Szuta wrote in message ...
>I think that this might be a problem with the python GC.  Basically you
>create circular lists,  and because their reference count never goes down
>to zero, the GC never frees them.  For example:
>ython 1.5.2 (#1, Feb  1 2000, 16:32:16)  [GCC egcs-2.91.66 19990314/Linux
>(egcs- on linux-i386
>Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>>> while 1 == 1:
>...     x = [1]
>...     y = [2]
>...     x[0] = y
>...     y[0] = x
>...
>
>This will eat up your memory like there is no tomorrow.  I think that the
>problem that you're describing my be similar.

No, I understand that - my program is explicitly designed to consume
all memory by progressively consuming smaller and smaller blocks,
throwing exceptions at each size.  My point is that eventually Python
/crashes/ by attempting to write to low memory instead of failing with
a MemoryError.  (Running your code on Win98 produced mixed results for
me, sometimes throwing MemoryError and sometimes crashing, probably
because the memory allocation is less controlled than in my sample.)

So I need a ceval.c expert to vet my change.  Let me reiterate that
this is not an academic case, as beta-testing with users has produced
crashes on Win98 machines with little virtual memory.

>On Mon, 19 Jun 2000 22:20:46 -0700, Phil Mayes <nospam at bitbucket.com>
wrote:
>>The following program progressively allocates all memory:
>>    size = 1 << 20
>>    list = [None,]
>>    while size:
>>        try:
>>            mem = [None] * size
>>            mem[0] = list
>>            list = mem
>>        except:
>>            size = size / 2
>>
>>It fails with an access violation.  (Turn off virtual memory
>>to provoke it.)  This is not a theoretical situation for me:
>>I have a beta release in the field that is crashing like this.
>>The immediate cause is this:
>>
>>1. we are handling a MemoryError
>>2. the following call cannot allocate a traceback object
>>     ceval.c line 1800:    PyErr_Fetch(&exc, &val, &tb);
>>3. the NULL pointer at tb is pushed here:
>>     ceval.c line 1816:    PUSH(tb);
>>     ceval.c line 1817:    PUSH(val);
>>     ceval.c line 1818:    PUSH(exc);
>>4. later it is popped here and its ref count is decremented:
>>     ceval.c line 682:    case POP_TOP:
>>     ceval.c line 683:        v = POP();
>>     ceval.c line 684:        Py_DECREF(v);
>>     ceval.c line 685:        continue;
>>
>>This is with 1.5.2 but the crash still happens with 1.6a2.
>>At this stage I am way out of my depth, and  the only way I
>>see to fix this is to change Py_DECREF to Py_XDECREF, which
>>is a (minor?) inefficiency. Can anyone recommend a better way?
>>
>>And should I report this at http://www.python.org/python-bugs?
>>I do not have access to the current CVS tree.
>>
>>TIA, Phil Mayes
>>--
>>pmayes AT olivebr DOT com
>>
>>
>>
>
>
>--
>---------------------------------------------------------------------------
----
>Pat Szuta www.sourcelight.com
>Software Engineer "Guiding you to
>Sourcelight Technologies great choices"(TM)
>(847)-475-1000 ext. 209
--
Phil Mayes    pmayes AT olivebr DOT com