[ python-Bugs-1000914 ] Carbon.CF.CFMutableArray hangs interpreter

[SourceForge.net]

Bugs item #1000914, was opened at 2004-07-30 22:18
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1000914&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Macintosh
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Ronald Oussoren (ronaldoussoren)
Assigned to: Jack Jansen (jackjansen)
Summary: Carbon.CF.CFMutableArray hangs interpreter

Initial Comment:
$ /opt/python2.4/bin/python
Python 2.4a1+ (#1, Jul 30 2004, 20:22:17) 
[GCC 3.3 20030304 (Apple Computer, Inc. build 1495)] on darwin
Type "help", "copyright", "credits" or "license" for more 
information.
>>> from Carbon.CF import *
>>> c = CFArrayCreateMutable(0)
>>> isinstance(c, CFMutableArrayRef)
True
>>> del c

The interpreter hangs after deleting c. This also happens when the 
call to isinstance is left out.

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

>Comment By: Jack Jansen (jackjansen)
Date: 2006-05-21 22:50

Message:
Logged In: YES 
user_id=45365

I fixed a number of bugs in bgen the last couple of months, including one that 
had to do with base class destructors not being called. Maybe I re-introduced 
the bug somehow, with those fixes?

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2006-05-20 15:32

Message:
Logged In: YES 
user_id=580910

I've just fixed it again in the trunk, and the bug is present in 2.4.3 as wel. Very 
strange...

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2004-08-15 14:47

Message:
Logged In: YES 
user_id=580910

Yup, the issue is no longer there.

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

Comment By: Jack Jansen (jackjansen)
Date: 2004-08-14 21:58

Message:
Logged In: YES 
user_id=45365

Ronald,
I think I fixed this in CVS just before my holidays. Could you please 
check?

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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2004-08-07 18:14

Message:
Logged In: YES 
user_id=580910

It's infinite recursion...

- CF.CFMutableArrayRef has is a subtype of CF.CFArrayRef
- Both tp_del's call 'self->ob_type->tp_base->tp_dealloc' to deallocate
   the instance.
- When the instance is an CFMutableArrayRef self->ob_type->tp_base
   is CFArrayRef, which means we get:

1. Object refcount is 0, call tp_dealloc
2. Enter CFMutableArrayRefObj_dealloc
3. Call self->ob_type->tp_dealloc
4. Enter CFArrayRefObj_dealloc
5. Call self->ob_type->tp_dealloc
6. Enter CFArrayRefObj_dealloc
7. ...

I guess the right change is in Tools/bgen/bgen/bgenObjectDefinition.py:
outputDealloc.

Near line 138 this prints the problematic 'self->ob_type->tp_base-
>tp_dealloc'. I'd change this to:

    Output("%s.tp_dealloc((PyObject*)self);"%(self.basetype,))


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

Comment By: Ronald Oussoren (ronaldoussoren)
Date: 2004-07-30 22:27

Message:
Logged In: YES 
user_id=580910

when I use gdb to check where the program hangs I always end up in 
CFArrayRefObj_dealloc. This also happens when I continue to program 
and break again later on.

It doesn't seem to be infinite recursion, the stack is 8 levels deep with 
the code mentioned earlier.

However:
(gdb) where
#0  0x00551f98 in CFArrayRefObj_dealloc (self=0x37f0e0) at /Volumes/
Data/Users/ronald/Software/python-HEAD/dist/src/Mac/Modules/cf/
_CFmodule.c:525
#1  0x0008879c in PyEval_EvalFrame (f=0x60d820) at Python/ceval.c:
1662
#2  0x0008a4bc in PyEval_EvalCodeEx (co=0x2, globals=0x59e54, 
locals=0x552308, args=0x16c, argcount=6312944, kws=0x874a0, 
kwcount=1, defs=0x60d96c, defcount=0, closure=0x0) at Python/
ceval.c:2697
#3  0x0008d648 in PyEval_EvalCode (co=0x37f0e0, globals=0x59e54, 
locals=0x55e1d4) at Python/ceval.c:448
#4  0x0000c9a0 in run_node (n=0x16c, filename=0x59e54 "\201^", 
globals=0x2, locals=0x60d96c, flags=0x0) at Python/pythonrun.c:1255
#5  0x0000c128 in PyRun_SimpleFileExFlags (fp=0xa0009818, 
filename=0xbffffc9e "t.py", closeit=6346784, flags=0x377a92) at Python/
pythonrun.c:850
#6  0x00006328 in Py_Main (argc=3533392, argv=0xbffffc9e) at 
Modules/main.c:413
#7  0x00001ee4 in _start (argc=3533392, argv=0xa0009818, 
envp=0xbffffc9e) at /SourceCache/Csu/Csu-46/crt.c:267
#8  0x00001d58 in start ()
(gdb) p self
$3 = (CFArrayRefObject *) 0x37f0e0
(gdb) p *self
$4 = {
  ob_refcnt = 0, 
  ob_type = 0x55e2e4, 
  ob_itself = 0x0, 
  ob_freeit = 0x90190b98 <CFRelease>
}
(gdb) p self->ob_type->tp_base
$5 = (struct _typeobject *) 0x55e1d4
(gdb) p self->ob_type->tp_base->tp_dealloc
$6 = 0x551f48 <CFArrayRefObj_dealloc>
(gdb) 

And CFArrayRefObj_dealloc is:

static void CFArrayRefObj_dealloc(CFArrayRefObject *self)
{
        if (self->ob_freeit && self->ob_itself)
        {
                self->ob_freeit((CFTypeRef)self->ob_itself);
                self->ob_itself = NULL;
        }
        self->ob_type->tp_base->tp_dealloc((PyObject *)self);
}

BTW: Python 2.4a1+ from anon-CVS as of today, running on OSX 10.3.4 
with Xcode 1.2 (gcc 3.3)

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

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