Re: TreeView crashes X server?

[James Henstridge <james daa com au>]

Arjan J. Molenaar wrote:

> On Fri, 2001-12-14 at 11:13, James Henstridge wrote:
>
> > Arjan J. Molenaar wrote:
> >
> > > Hi, 
> > >
> > > I'm having some problems with the TreeView stuff of GTK+ 2.0. It seems
> > > like this widget somehow causes an X server crash. If for some reason
> > > the X server itself doesn't crash I get a message that I should use the
> > > --sync option to produce reliable coredumps. However, if I turn on this
> > > option, the program works (mostly) fine. 
> > >
> > > Well, I encountered the problem when I was writing a small program in
> > > Python (and used the PyGTK bindings). This (Python) might be the
> > > problem, but according to some checks I did, the problem seems to be
> > > somewhat more sophisticated.
> > If you are using the (horrendously) leaky GenericTreeModel python class 
> > as a base, it could be that you are simply running out of memory. 
> > Generally, a client can't crash the X server (if it can, then it is a 
> > bug in the X server).  However, if the system runs out of memory, you 
> > may run into problems.
>
> As far as I can see, the system is not running out of memory (or a
> request is made for a memory segment > my mem)...
>
> BTW. What is a good way to do some memory debuging on the tree
> model/view? It works like a charm, but if it really leaks that much,
> it's not really usable...
The GenericTreeModel will leak one python object reference for each 
GtkTreeModel method that fills in a GtkTreeIter (as it doesn't know when 
the iter is not needed any more.  If you always return the same python 
objects, you will simply get reference leaks.  If you return different 
objects each time, then you will see memory leaks.

It might be worth adding a flag to GenericTreeModel in pygtk so that you 
can switch between the current leaky behaviour and one where it doesn't 
ref the objects, and may crash if you don't keep references to the 
objects elsewhere.

James.

--
Email: james daa com au
WWW:   http://www.daa.com.au/~james/