Re: [Pysdl-devel] rect leak

[Pete S. <psh...@me...>]

> Whoa, so this could be what makes my app eat most of my 256Mb? I had an
> loop which just polled the event mechanism for new events and just waited 
> for a keypress, and it leaked 5Mb/s. Not too funny. I converted to using
> wait instead, and now it consumes a lot less memory, but still chews up *a
> lot*, compared to what the app does (30Mb).

(shoot, sourceforge seems down this mornin. there goes my
second brain located in the pysdl mail archives)

according to Mark Baker. this leak was spotted and fixed up a
couple releases ago. it managed to sneak its way back into
the 0.0.7 release, and is fixed up for the next release.

it's an easy one-line fix if you're prepared to go in
and get it yourself. in the sdl_events_poll routine, you
can see the call to allocate the "s_event_ref" object.
before returning -1, you need to free "s_event_ref", because
it's not being used.

The way you have it now, there will be no leak when there
are events waiting to be polled, you will leak memory each
time you call events_poll() and there are no events.

i'm not sure what you're app is doing, but if it's GUI, and
no animations going on, you can use sdl_events_wait, which
will only return when an event is ready. 


> Btw, is it my responsibilty to explicitely delete surfaces etc I don't
> need anymore? I have a few of these, and they are not circularly
> referenced, so thay should be garbage collected, but my app never seems to
> release any memory. Thememory  usage keeps increasing as I "surf" through
> my dialogs 

your assumption is definitely correct. coming from so much 'C'
i occasianally feel a bit uncomfortable just leaving that surface
go inside my funcion. (knowing it's the last reference)

if you're using global variables to point to your surfaces, then
there's a really good chance they're not being cleaned up. also if
the images are class members (not class instance members, big diff)
they won't be getting cleaned up either. you must use "del" on
variables like these when you are done with the images, or just
reassign the variables to "None" or something else.

if you compile SDL with "CHECK_LEAKS" defined, it will do its
own surface reference counting and memory tracking. it might be
worth your time to recompile SDL this way and run your app. when
you exit you should get extra information about leaked surfaces.

hmm, other than that, really doublecheck for those circular
references. although now with the 2.0 Garbage Collection, that
might not even matter?