Allegro.cc - Online Community

Allegro.cc Forums » Allegro Development » Allegro 5.0.6 released!

This thread is locked; no one can reply to it. rss feed Print
 1   2   3 
Allegro 5.0.6 released!
Elias
Member #358
May 2000

Because then an actual leak cannot print that message any longer (since now there is a pool, just a useless one).

--
"Either help out or stop whining" - Evert

Arvidsson
Member #4,603
May 2004
avatar

I get that. I don't understand why it's being useless though, but then again I'm a beginner at Cocoa.

Matthew Leverton
Supreme Loser
January 1999
avatar

Say you call an Allegro function 100,000 times throughout the course of your game and each time it returns a huge object marked for auto-release. If that global pool is the only one in place, then those objects will sit around until the program exits.

The only difference (from having no pool at all) is you will not get a warning; thus, you are worse off than before.

So the proper fix is to localize the pools to free the memory sooner or to release the objects manually when they are no longer needed.

Arvidsson
Member #4,603
May 2004
avatar

But isn't the pool drained every cycle in the event loop? Or should be at least?

Elias
Member #358
May 2000

But isn't the pool drained every cycle in the event loop? Or should be at least?

No, pools are per thread and only the main thread has an event loop. But the main thread has no user pool anyway since appkit already creates (and regularly drains) it for us.

--
"Either help out or stop whining" - Evert

AMCerasoli
Member #11,955
May 2010
avatar

What the... This thread was death for about 8 days, I revived it to ask what does "TDM" stand for, and you guys still talking about programming like a crazy... This remind those movies when the TV fails and the guy kick it to make it work again...

I'm gonna try again: What does "TDM" stand for?

Thermo Dynamic Multi-Thread?
Temporal Day Month?
Tits Drogs & Music?
This Doesn't Matters?
Today Dance More?

Thanks.

SquizzZ
Member #4,174
December 2003

It stands for Twilight Dragon Media. TDragon is a guy who single handely releases up-to-date binaries of GCC for Windows, because official MinGW project for some reason doesn't *

* might be wrong, haven't checked official MinGW site for some time, but they stopped releases at 3.4.5 at some point for couple of years. I'm using TDragon version since then..

AMCerasoli
Member #11,955
May 2010
avatar

Ohhh, I see. And I was thinking about threads or something... Thanks man!.

TeaRDoWN
Member #8,518
April 2007
avatar

"...al_draw_filled_pieslice and al_draw_pieslice..."

Pure pure love!

furinkan
Member #10,271
October 2008
avatar

Arthur Kalliokoski
Second in Command
February 2005
avatar

furinkan said:

Allegro programatically makes pie?!

You don't need Allegro for that.

They all watch too much MSNBC... they get ideas.

SiegeLord
Member #7,827
October 2006
avatar

furinkan said:

Allegro programatically makes pie?!

Be careful when using that function. Allegro's budget doesn't allow for more than 3-4 invocations of it per month [1].

References

  1. More invocations are allowed if you ask for smaller slices

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

jmasterx
Member #11,410
October 2009

Finally I can put Pie on my vtable and feed my linked-list of children!

furinkan
Member #10,271
October 2008
avatar

Yes, that's all good and well... but, can wikipedia tell me how to programatically generate filled pie?

I've got $28USD in a Nigerian bank account for anyone who can make my Allegro work. Something about allegro_cherry_filling.h not being found. I insist on using a closed source viewer; exchanging text is too secure.

douglett
Member #13,682
October 2011

Sorry to derail your conversation about pie (heh), but was their any suggested resolution to the osx 10.6.x memory leak issue described by Todd Cope? Should I wait until the next version, move back to 5.0.5, or just try and ignore it?

Cheers.

Elias
Member #358
May 2000

Someone has to find the leak. Since it doesn't happen on 10.7 (or is not reported there at least) I'm not sure how to do that myself.

--
"Either help out or stop whining" - Evert

Arvidsson
Member #4,603
May 2004
avatar

I could try but I'm not sure how to go about it.

Elias
Member #358
May 2000

Can you try replacing this line

https://github.com/elias-pschernig/allegro5/blob/master/src/macosx/osx_app_delegate.m#L279

with

if (0)

and see if there's any change in the amount of runtime warnings?

--
"Either help out or stop whining" - Evert

Arvidsson
Member #4,603
May 2004
avatar

No difference. I changed the line, typed make in the examples directory and ran ex_draw.

The first breakpoint now revealed this:

#0  0x00007fff86157d34 in __NSAutoreleaseNoPool ()
#1  0x00007fff860a2e79 in _CFAutoreleasePoolAddObject ()
#2  0x00007fff860a2be6 in -[NSObject(NSObject) autorelease] ()
#3  0x00007fff860a51d8 in +[NSDictionary dictionaryWithObjectsAndKeys:] ()
#4  0x00007fff83d4115a in -[NSApplication setDelegate:] ()
#5  0x00000001000947d8 in _al_osx_run_main (argc=1, argv=0x7fff5fbff960,
real_main=<value temporarily unavailable, due to optimizations>) at /Users
/arvidsson/Projekt/allegro/src/macosx/osx_app_delegate.m:334
#6  0x000000010013df40 in main (argc=<value temporarily unavailable, due to 
optimizations>, argv=<value temporarily unavailable, due to optimizations>) at 
/Users/arvidsson/Projekt/allegro/addons/main/osx_main.m:34

So, yes a slight difference. The objects within the if statement are not created and thus not leaked. What I don't get is that the run loop should create a new autorelease pool before it dispatches the applicationDidFinishLaunching event, right? Could there be any reason this might not happen?

edit: I realized now that I didn't really change anything in applicationDidFinishLaunching, which was what I was thinking. Disregard that.

edit2:

From Apple's NSApplication class reference:

Quote:

The NSApplication class sets up autorelease pools (instances of the NSAutoreleasePool class) during initialization and inside the event loop—specifically, within its initialization (or sharedApplication) and run methods. Similarly, the methods the Application Kit adds to NSBundle employ autorelease pools during the loading of nib files. These autorelease pools aren’t accessible outside the scope of the respective NSApplication and NSBundle methods. Typically, an application creates objects either while the event loop is running or by loading objects from nib files, so this lack of access usually isn’t a problem. However, if you do need to use Cocoa classes within the main() function itself (other than to load nib files or to instantiate NSApplication), you should create an autorelease pool before using the classes and then release the pool when you’re done. For more information, see NSAutoreleasePool in the Foundation Framework Reference.

Emphasis added. Does this explain anything?

edit3: What is the reason for not creating an autoreleasepool for the thread created for the user's main? (e.g. in app_main)

edit4:

Elias: are you sure ARC is disabled when you compile on Lion? I can't find any reasons (on google) why I would get these warnings and not you.

Elias
Member #358
May 2000

What if you create a pool before line 334 then release it afterwards (Before the NSApp run). I.e. like this:

NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
[NSApp setDelegate: app_delegate];
[pool drain];
[NSApp run];

Also create a pool around that nib stuff in the if above. Does that fix all messages?

What is the reason for not creating an autoreleasepool for the thread created for the user's main? (e.g. in app_main)

It hides memory leaks (if the pool is never drained). We don't want even a single leak in all of Allegro so we do everything which helps detect them.

are you sure ARC is disabled when you compile on Lion?

Yeah. The reason you get the warnings is that you use OSX 10.6. I'm still not sure what exactly Apple changed (or what changed in the Allegro source, but I don't think anything did). But looks like we're close to finding out, depending on what the result of the above change is.

--
"Either help out or stop whining" - Evert

Arvidsson
Member #4,603
May 2004
avatar

The warnings are still there, but the backtraces are more explicit (I still have if(0) in the source, otherwise those warnings would show up first and the backtraces were the same).

Here are two of them:

#0  0x00007fff86157d34 in __NSAutoreleaseNoPool ()
#1  0x00007fff860a2e79 in _CFAutoreleasePoolAddObject ()
#2  0x00007fff860a2be6 in -[NSObject(NSObject) autorelease] ()
#3  0x00000001000906fb in _al_osx_get_path (id=<value temporarily unavailable, 
due to optimizations>) at /Users/arvidsson/Projekt/allegro/src/macosx/system.m:586
#4  0x0000000100059509 in early_get_exename_path [inlined] () at /Users
/arvidsson/Projekt/allegro/src/system.c:116
#5  0x0000000100059509 in read_allegro_cfg [inlined] () at /Users/arvidsson
/Projekt/allegro/src/system.c:162
#6  0x0000000100059509 in al_install_system (version=83887361, 
atexit_ptr=0x7fff8365ec07 <atexit>) at /Users/arvidsson/Projekt/allegro/src/system.c:244
#7  0x0000000100004885 in _al_mangled_main () at /Users/arvidsson/Projekt
/allegro/examples/ex_draw.c:285
#8  0x0000000100094cc7 in call_user_main [inlined] () at /Users/arvidsson
/Projekt/allegro/src/macosx/osx_app_delegate.m:214
#9  0x0000000100094cc7 in +[AllegroAppDelegate app_main:] (self=<value 
temporarily unavailable, due to optimizations>, _cmd=<value temporarily 
unavailable, due to optimizations>, arg=<value temporarily unavailable, due to 
optimizations>) at /Users/arvidsson/Projekt/allegro/src/macosx
/osx_app_delegate.m:225
#10 0x00007fff88b0f114 in _NSThread__main_ ()
#11 0x00007fff8363cfd6 in _pthread_start ()
#12 0x00007fff8363ce89 in thread_start ()

#0  0x00007fff86157d34 in __NSAutoreleaseNoPool ()
#1  0x00007fff860a2e79 in _CFAutoreleasePoolAddObject ()
#2  0x00007fff860a2be6 in -[NSObject(NSObject) autorelease] ()
#3  0x00007fff88b10423 in +[NSString stringWithFormat:] ()
#4  0x000000010008fbb0 in osx_init_mouse () at /Users/arvidsson/Projekt/allegro/src/macosx/qzmouse.m:216
#5  0x0000000100056736 in al_install_mouse () at /Users/arvidsson/Projekt
/allegro/src/mousenu.c:56
#6  0x00000001000048cf in _al_mangled_main () at /Users/arvidsson/Projekt
/allegro/examples/ex_draw.c:292
#7  0x0000000100094cc7 in call_user_main [inlined] () at /Users/arvidsson
/Projekt/allegro/src/macosx/osx_app_delegate.m:214
#8  0x0000000100094cc7 in +[AllegroAppDelegate app_main:] (self=<value 
temporarily unavailable, due to optimizations>, _cmd=<value temporarily 
unavailable, due to optimizations>, arg=<value temporarily unavailable, due to 
optimizations>) at /Users/arvidsson/Projekt/allegro/src/macosx
/osx_app_delegate.m:225
#9  0x00007fff88b0f114 in _NSThread__main_ ()
#10 0x00007fff8363cfd6 in _pthread_start ()
#11 0x00007fff8363ce89 in thread_start ()

edit:

Didn't see the pool around the nib stuff. I placed a pool around everything in _al_osx_run_main, and that made those warnings go away. You didn't respond to the NSApplication reference - if I understood it correctly there is no pool in _al_osx_run_main at all, hence the warnings.

I might be missing something crucial here but, if you're not explicitly using init/release in the allegro code, then of course there will be warnings because the objects you create are autoreleased with no pool in place - both in _al_osx_run_main and in the separate thread where the user's main is executed. Adding a pool in the created thread might very well hide memory leaks, but would it be possible to somehow drain the pool for the user automatically?

Elias
Member #358
May 2000

No, it has to be done explicitly. There is no garbage collection or automatic reference counting going on. And yes, there should be no pool. What we want is create the pool before a function needing it and destroying it afterwards.

Apparently there is a function call (in some OSX 10.6 specific part of the code) where the pool was forgotten. We simply have to figure out where. Just imagine we would have had a pool around _al_osx_run_main - then this specific memory leak your warning messages are about would probably never have been detected and Allegro programs would eat more and more memory on OSX the longer they run.

What if you create a pool inside _al_osx_get_path and drain it again before returning? Does that fix all of the warnings? (Without the pool all around _al_osx_run_main of course.)

--
"Either help out or stop whining" - Evert

Arvidsson
Member #4,603
May 2004
avatar

Elias said:

What if you create a pool inside _al_osx_get_path and drain it again before returning? Does that fix all of the warnings?

No, that removes that specific warning.

Quote:

We simply have to figure out where.

I'm not sure it's as simple as that. The pool that hid these warnings weren't removed that long ago right? So, these problems could have been there a long time. It's still weird why the warnings don't show up on Lion though.

Correct me if I'm wrong, but here's my line of thought. There is no pool in the user's main. Let's take ex_draw as an example. al_install_mouse() is called, which calls osx_init_mouse(), which calls stringWithFormat:, which creates an autoreleased object with no pool in place. The same happens in al_init_image_addon(), which calls _al_osx_register_image_loader(), which calls imageFileTypes:, which creates an autoreleased object with no pool in place.

The solution, albeit tedious, seems to be to create and drain a pool inside every function where autoreleased objects are created.

I don't see how a missing pool somewhere could fix all the other warnings.

Quote:

And yes, there should be no pool.

Just to make sure. I was talking about how the AppKit's pool isn't created until NSApp run: is called. Thus, in _al_osx_run_main there is no pool in place when the autoreleased objects within the if() are created. I wasn't refering to the pool that hides all the leaks that are still there (i.e. the pool that was recently removed in the allegro source).

Elias
Member #358
May 2000

I'm not sure it's as simple as that. The pool that hid these warnings weren't removed that long ago right?

Yeah. The global pools were there initially still from the A4 port which was leaking everywhere - which we only discovered when analyzing memory usage of the A5 IOS port.

Quote:

The solution, albeit tedious, seems to be to create and drain a pool inside every function where autoreleased objects are created.

Yes, that's what I'm trying to say. And I would consider it one of the least tedious things when writing something like A5 :P It just appears the code was originally written with some wrong conception about Objective C memory management.

Basically the OSX API uses two kinds of memory allocation:

1. Basic reference counting:

[object alloc] ... [object release]

This one is just like malloc/free. If you alloc something you must release it later.

2. Autorelease pools

Here an object is not released but instead added to a list (the autorelease pool). So it works like:

[[pool alloc]init]

...

[object alloc] [object autorelease] ...

...

[pool drain]

In a "normal" objective C application, the GUI system's update function will in each tick create a pool, then call all the user events, then drain the pool. So in the user application it's enough to allocate and auto-relese objects since at most a few ms later the pool will get drained (and your object's freed) by the system.

But in the case of Allegro we don't have a place where we could create and drain those pools - the user's main() function can just go into an endless loop where it checks the key state and redraws the screen, for all we know.

The solution to this is to either change how Allegro works (and for example require each thread using Allegro functions to regulary call some function) - or to make sure that we drain each autorelease pool right after use. Right now the preferred solution is the latter.

Anyway, my impression was that the OSX port has no more calls left without a pool (since otherwise those nice warning messages appear). Now it looks like there are quite a few (I'm still fairly certain it's not more than 10 or so) places - but for some reason they are not reported with OSX 10.7.

--
"Either help out or stop whining" - Evert

Arvidsson
Member #4,603
May 2004
avatar

Thanks for the explanation. I can go through the examples and add the missing pools, that should cover all warnings as I guess the examples use most of A5's functionality. Do you want me to create diffs and send you?

 1   2   3 


Go to: