Commit 01a1f740 authored by Kevin Modzelewski's avatar Kevin Modzelewski

Try to make some weakref tests more reliable

They test what happens when a weakref's referent gets collected, but
I guess in certain build configurations we would keep the object alive
due to some sort of different memory layout (got saved in a CSR or
a stack slot that didn't get rewritten, etc).

Adding some extra function calls seems to help, though it's hard to tell
how reliable it is.
parent c4fe264a
......@@ -37,7 +37,7 @@ PyAPI_DATA(PyTypeObject*) int_cls;
#define PyInt_Type (*int_cls)
// Pyston change: (op)->ob_type --> Py_TYPE(op)
// #define PyInt_Check(op) \
// #define PyInt_Check(op)
// PyType_FastSubclass((op)->ob_type, Py_TPFLAGS_INT_SUBCLASS)
#define PyInt_Check(op) \
PyType_FastSubclass(Py_TYPE(op), Py_TPFLAGS_INT_SUBCLASS)
......
......@@ -11,6 +11,12 @@ def doStuff():
wr = weakref.ref(meth, cb)
return wr
def fact(n):
if n <= 1:
return n
return n * fact(n-1)
w = doStuff()
fact(10) # try to clear some memory
gc.collect()
......@@ -8,7 +8,13 @@ def doStuff():
wr = weakref.ref(meth)
return wr
def fact(n):
if n <= 1:
return n
return n * fact(n-1)
w = doStuff()
print fact(10) # try to clear some memory
gc.collect()
print w()
......@@ -36,7 +36,7 @@ IMAGE = "pyston_dbg"
KEEP_GOING = False
FN_JUST_SIZE = 20
EXTRA_JIT_ARGS = []
TIME_LIMIT = 15
TIME_LIMIT = 25
# For fun, can test pypy.
# Tough because the tester will check to see if the error messages are exactly the
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment