| Re: [AD] SF.net SVN: alleg:[14994] allegro/branches/5.1 |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Sun, 22 Apr 2012 21:48:01 +0200
Evert Glebbeek <eglebbk@xxxxxxxxxx> wrote:
> On 28 Aug 2011, at 15:17 , elias@xxxxxxxxxx wrote:
> > - Removed some global pools we never drain - those serve no purpose
> > except hiding leaks (more and more objects get added to the pool
> > and are never freed (before program exit). Instead, memory must be
> > released when not used any longer so the garbage collecttor will
> > collect them.)
>
> I don't know whether this was discussed at some point or not
> (couldn't find anything when searching my mail though) but I'm
> guessing this is the reason I get tons of complaints of memory leaks
> printed to the console with 5.1. While I agree with the intention
Are you using OSX 10.6? I don't get any runtime warnings here with 10.7.
> (memory leaks should be fixed, not hidden) I'm wondering whether the
> approach here doesn't take things too far. First of all, my
> understanding is that if you create your own threat then you *have*
> to create a release pool for it. Especially considering that some of
> the complaints I seem to be coming from Cocoa itself rather than
> objects Allegro creates and then leaves dangling, I suggest that we
> restore the release pool for the mangled main (see patch below) and
> drain it periodically (not sure how to do that though).
>
You drain it periodically by creating and draining a pool in each
"tick". Cocoa does that in each of it's own GUI ticks. Allegro
obviously cannot work that way, unless we add a function which has to
be periodically called by the user.
Just creating a pool in the beginning of the thread then draining it
when the thread quits is useless, *if* my interpretation is right. The
Apple code examples I've looked at do create and drain the pool around
calls into their APIs though and never put a pool "all around" the
program.
> If I'm missing something and Allegro itself is actually leaking
> objects, does anyone have a suggestion for where to start looking for
> places where one might fix "Object of class NSPathStore2 autoreleased
> with no pool in place"?
>
Just set a breakpoint to __NSAutoreleaseNoPool. It should give you a
full backtrace of the allocation which is attempted while no pool is in
place. I cannot do it myself since I only have access to OSX 10.7.
There was a thread on allegro.cc where someone with OSX 10.6 offered to
do this but he hasn't got around to it yet it seems. [1]
[1] http://www.allegro.cc/forums/thread/609685/952227#target