Re: [Pyobjc-dev] crasher demo app

[Bob I. <bo...@re...>]

On Mar 25, 2004, at 1:18 AM, Burris T. Ewell wrote:

> Okay, here is a bare bones implementation of what I was describing.
>
> http://www.gigagig.org/BT/mcfoo.tgz
>
> Start this up.  It helps to click on the cells, try to drag them.  
> Sometimes it will hang.  Sometimes it will crash like this:
>
> *** malloc[1540]: Deallocation of a pointer not malloced: 0x726df0; 
> This could be a double free(), or free() called with the middle of an 
> allocated block; Try setting environment variable MallocHelp to see 
> tools to help debug
> *** malloc_zone_malloc[1540]: argument too large: 4294967292
>
> mcfoo has exited due to signal 10 (SIGBUS).

Bill brought this to my attention off-list.  I haven't looked at your 
problem, however it's relatively safe to say that it's one of two 
things:

(1) Reference counting.  Some of Cocoa doesn't retain things (like the 
table data source, I think).  So you will have to keep a reference to 
things like this somewhere on your own.  This sucks, most of us think 
it's a bug in Cocoa, and we have filed reports in radar.  If this does 
turn out to be your problem, I suggest filing a duplicate bug.

(2) Multithreading.  Multithreading, especially in Python, is just not 
the right solution.  Even without Python, Cocoa is not re-entrant, and 
the recommended way to communicate between threads in Objective C is 
via DO (or some similar safe indirection).  You might as well just use 
processes.  They aren't as expensive as they used to be (a process is a 
mach thread with its own copy-on-write memory space), they prevent you 
from making stupid near-impossible-to-debug bugs because each one plays 
in its own memory sandbox, and you can end up scaling your application 
to multiple machines when/if you ever need to.

	(2b) Instead of using multiple proceses, it's possible to use 
Stackless Python, where you can get the things you want from threads 
(writing blocking-style code that is "asynchronous") without the evil 
things that pre-emptive threads bring to the table because you do your 
own scheduling.  I'm not sure if I should recommend this approach right 
now though.  The Stackless CVS is somewhat volatile because we just had 
a sprint, you currently need to know what you're doing in order to use 
it effectively, and there isn't much in the way of documentation -- 
especially when interacting with Cocoa.  All of these things will be 
solved, just not this week :)

If the problem is related to multithreading, I'd like to help you 
refactor it into either multiprocess or stackless, but I can't offer 
much assistance until next week at the earliest.  And hey, if you're 
lucky, this crash might pique Ronald's interest, and he might find and 
fix this bug before I get a chance to even look at it ;)

-bob

P.S.:  Please don't say "but I really do want to use threads".  Trust 
me, you don't.  Even Guido recommends the multi-process model (as per 
his keynote this morning), because the GIL is just too hard to get rid 
of without killing performance and/or overcomplicating the 
interpreter's implementation, and he doesn't want to adopt the 
"separate object space" sort of thread model (the sane kind, that 
actually works in practice).