Received: by 10.43.105.135 with SMTP id dq7mr3244266icc.3.1347780257558;
        Sun, 16 Sep 2012 00:24:17 -0700 (PDT)
X-BeenThere: wxpython-dev@googlegroups.com
Received: by 10.50.157.164 with SMTP id wn4ls2677855igb.0.canary; Sun, 16 Sep
 2012 00:24:17 -0700 (PDT)
Received: by 10.50.153.225 with SMTP id vj1mr1954188igb.3.1347780257173;
        Sun, 16 Sep 2012 00:24:17 -0700 (PDT)
Received: by 10.50.57.75 with SMTP id g11msigq;
        Sat, 15 Sep 2012 22:32:07 -0700 (PDT)
Received: by 10.66.84.199 with SMTP id b7mr1526341paz.11.1347773527459;
        Sat, 15 Sep 2012 22:32:07 -0700 (PDT)
Received: by 10.66.84.199 with SMTP id b7mr1526340paz.11.1347773527446;
        Sat, 15 Sep 2012 22:32:07 -0700 (PDT)
Return-Path: <pwil3...@bigpond.net.au>
Received: from nschwmtas03p.mx.bigpond.com (nschwmtas03p.mx.bigpond.com. [61.9.189.143])
        by gmr-mx.google.com with ESMTP id p7si2378525pby.0.2012.09.15.22.32.06;
        Sat, 15 Sep 2012 22:32:07 -0700 (PDT)
Received-SPF: pass (google.com: domain of pwil3...@bigpond.net.au designates 61.9.189.143 as permitted sender) client-ip=61.9.189.143;
Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of pwil3...@bigpond.net.au designates 61.9.189.143 as permitted sender) smtp.mail=pwil3...@bigpond.net.au
Received: from nschwcmgw09p ([61.9.190.169]) by nschwmtas03p.mx.bigpond.com
          with ESMTP
          id <20120916053205.RKIJ11739.nschwmtas03p.mx.bigpond.com@nschwcmgw09p>
          for <wxpython-dev@googlegroups.com>;
          Sun, 16 Sep 2012 05:32:05 +0000
Received: from mudlark.pw.nest ([124.185.148.112])
	by nschwcmgw09p with BigPond Outbound
	id zhY51j0052RkRGk01hY5Nm; Sun, 16 Sep 2012 05:32:05 +0000
X-Authentication-Info: Submitted using ID pwil3...@bigpond.net.au
X-Authority-Analysis: v=2.0 cv=HORB5/Rv c=1 sm=1
 a=UHjtSLvITkAXwjSMK/Cp3g==:17 a=NTPdI6uDeGEA:10 a=8nJEP1OIZ-IA:10
 a=Sv2sojjTAAAA:8 a=WQso3Z4dyy4A:10 a=UgwiewEW8y0ZHcDrouAA:9 a=wPNLvfGTeEIA:10
 a=qEied-PUxAPvTtw0:21 a=oQC3i7xfDf-CBphU:21 a=UHjtSLvITkAXwjSMK/Cp3g==:117
Message-ID: <50556455.3060...@bigpond.net.au>
Date: Sun, 16 Sep 2012 15:32:05 +1000
From: Peter Williams <pwil3...@bigpond.net.au>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120828 Thunderbird/15.0
MIME-Version: 1.0
To: wxpython-dev@googlegroups.com
Subject: Segmentation faults - a theory
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

As a newcomer (coming from PyGTK), I've been alarmed by the number of 
segmentation faults that I've experienced using wxPython.  These are the 
only such problems that I have ever experienced using Python and based 
on the workarounds I have used to dodge them (and the use of names such 
as Destroy() for object methods) I have developed a theory as to what's 
causing them.

I suspect that some of these Destroy() methods end up invoking memory 
release within the C++ code.  This can cause problems in Python in (at 
least) two ways:

1. there are still (active) references to the released memory and if 
these references are accessed a segmentation fault will result, and
2. Python's garbage collector doesn't notice that the memory has been 
released and tries to release it itself when it notices that the object 
is no longer accessible (i.e. normal procedure) resulting in a 
segmentation fault.

I think that the only long term solution to this problem is to stop 
invoking C++ functions that release memory (at least for memory that 
Python knows about) and trust the Python garbage collector to do its job.

In short, using two competing memory management mechanisms at the same 
time is asking for trouble.  There are no explicit memory management 
functions in Python for this reason.

Cheers
Peter
PS For the convenience of programmers, using a obj.Show(False) as a 
substitute for obj.Destroy() would have the desired effect from a user 
perspective.