[Python-bugs-list] [ python-Bugs-415660 ] Weak references cause illegal memory ref

[noreply@sourceforge.net]

Bugs item #415660, was updated on 2001-04-12 06:58
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=415660&group_id=5470

Category: Python Interpreter Core
Group: None
Status: Open
>Priority: 7
Submitted By: Duncan Booth (duncanb)
>Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: Weak references cause illegal memory ref

Initial Comment:
Python 2.1b2 on Windows 2000
I was playing with weak references and found that the 
following script (test.py) caused the program to crash 
reliably with the error '''The instruction 
at "0x1e12b486" referenced memory at "0x00007479". the 
memory could not be "read".'''

Program test.py
---------------------------------
import weakref
from sys import getrefcount
from thread import get_ident

class C:
    def __del__(self):
        print "object deleted", `self`

def callback(object):
    print get_ident(),"callback for deletion",`object`
    print get_ident(),"ref is", `ref`, `ref()`
    print get_ident(),"ref1 is", `ref1`, `ref1()`
    print get_ident(),"end of callback"

c = C()
ref = weakref.ref(c, callback)
ref1 = weakref.ref(c, callback)
print get_ident(),"c is",`c`
print get_ident(),"ref is", `ref`, `ref()`
print get_ident(),"ref1 is", `ref1`, `ref1()`
del c
print get_ident(),"c was deleted"
print get_ident(),"ref is", `ref`, `ref()`
print get_ident(),"ref1 is", `ref1`, `ref1()`
print get_ident(),"Done"
---------------------------------

The output from the program is as follows. Something 
strange seems to be happening as both callbacks seem 
to be active at the same time on the same thread(?), 
and at least one newline has gone missing (in case 
this gets wrapped: every print begins with 1332, and 
the second 'callback for deletion' print is not at the 
start of a line).
---------------------------------
D:\temp>\python21\python test.py
1332 c is <__main__.C instance at 007DDD0C>
1332 ref is <weakref at 0x798f8c; to 'instance' at 
0x7ddd0c> <__main__.C instance at 007DDD0C>
1332 ref1 is <weakref at 0x7d9f7c; to 'instance' at 
0x7ddd0c> <__main__.C instance at 007DDD0C>
1332 callback for deletion <weakref at 7d9f7c; dead>
1332 ref is <weakref at 0x798f8c; to 'instance' at 
0x7ddd0c> 1332 callback for deletion <weakref at 
798f8c; dead>
1332 ref is <weakref at 798f8c; dead> None
1332 ref1 is <weakref at 7d9f7c; dead> None
1332 end of callback
object deleted <__main__.C instance at 007DDD0C>
<__main__.C instance at 007DDD0C>
1332 ref1 is <weakref at 7d9f7c; dead> None
1332 end of callback

D:\temp>
---------------------------------



----------------------------------------------------------------------

>Comment By: Tim Peters (tim_one)
Date: 2001-04-12 23:29

Message:
Logged In: YES 
user_id=31435

Boosted priority, assigned to Fred.

The thread stuff is a distraction (throw out all the 
get_ident() stuff & it still blows up).

Problem goes away if the "print ... ref()" call in the 
callback is commented out.  Note that this is doing ref() 
within ref's own "I'm dead" callback, so it's at best odd 
code.  Here's a shorter case that blows up (and designed to 
survive SourceForge's whitespace lossage intact):

import weakref
def callback(object): print "in callback", repr(ref())
class C: pass
c = C()
ref = weakref.ref(c, callback)
ref1 = weakref.ref(c, callback)
del c

Does not blow up if "ref1 =" is commented out, or if repr() 
is not invoked in the callback.  As is, it prints

in callback in callback None
<__main__.C instance at 0079606C>

and then blows up.  In a debug build, a call to 
PyObject_ClearWeakRefs is "up the call stack", at the start 
of instance_dealloc.  The former is a pointer to function 
cleanup_helper at this time.  cleanup_helper is executing 
PyObject_CallFunction(callback, "O", current).  The 
callback is apparently done at the time of the blowup, and 
ceval.c's do_call is executing Py_XDECREF(callargs).  The 
first tuple item is being deallocated, when Py_XDECREF(op-
>ob_item[i]) calls _Py_Dealloc calls _Py_ForgetReference, 
and that's where it finally blows up, and because the op 
passed in already has op->ob_next == op->ob_prev == NULL.


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=415660&group_id=5470