This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Carbon.CF.CFMutableArray hangs interpreter
Type: Stage:
Components: macOS Versions: Python 2.4
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: jackjansen Nosy List: jackjansen, ronaldoussoren
Priority: normal Keywords:

Created on 2004-07-30 20:18 by ronaldoussoren, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (7)
msg21852 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2004-07-30 20:18
$ /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 
>>> from Carbon.CF import *
>>> c = CFArrayCreateMutable(0)
>>> isinstance(c, CFMutableArrayRef)
>>> del c

The interpreter hangs after deleting c. This also happens when the 
call to isinstance is left out.
msg21853 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2004-07-30 20:27
Logged In: YES 

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.

(gdb) where
#0  0x00551f98 in CFArrayRefObj_dealloc (self=0x37f0e0) at /Volumes/
#1  0x0008879c in PyEval_EvalFrame (f=0x60d820) at Python/ceval.c:
#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/
#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 "", closeit=6346784, flags=0x377a92) at Python/
#6  0x00006328 in Py_Main (argc=3533392, argv=0xbffffc9e) at 
#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>

And CFArrayRefObj_dealloc is:

static void CFArrayRefObj_dealloc(CFArrayRefObject *self)
        if (self->ob_freeit && 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)
msg21854 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2004-08-07 16:14
Logged In: YES 

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/

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

msg21855 - (view) Author: Jack Jansen (jackjansen) * (Python committer) Date: 2004-08-14 19:58
Logged In: YES 

I think I fixed this in CVS just before my holidays. Could you please 
msg21856 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2004-08-15 12:47
Logged In: YES 

Yup, the issue is no longer there.
msg21857 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2006-05-20 13:32
Logged In: YES 

I've just fixed it again in the trunk, and the bug is present in 2.4.3 as wel. Very 
msg21858 - (view) Author: Jack Jansen (jackjansen) * (Python committer) Date: 2006-05-21 20:50
Logged In: YES 

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?
Date User Action Args
2022-04-11 14:56:06adminsetgithub: 40661
2004-07-30 20:18:03ronaldoussorencreate