http://sourceforge.net/projects/alleg/files/allegro/5.0.6/
Changes from 5.0.5 to 5.0.6 (March 2012)
========================================
The main developers this time were: Trent Gamblin, Matthew Leverton,
Elias Pschernig, Paul Suntsov, Peter Wang.
Core:
- Added al_register_assert_handler.
Graphics:
- Added al_draw_tinted_scaled_rotated_bitmap_region.
- Added al_reset_clipping_rectangle convenience function.
- Added al_get_parent_bitmap.
- Fixed a bug in the OpenGL driver when drawing the backbuffer outside the
clipping rectangle of the target bitmap.
- Make blitting from backbuffer work when using multisampling on Windows/D3D.
Displays:
- Set ALLEGRO_MINIMIZED display flag on Windows (Zac Evans).
- Don't generate bogus resize events after restoring minimised window on
Windows.
- Fixed bug on Windows where two SWITCH_IN events were fired when window was
minimized/restored (Michael Swiger).
- Fixed inverted al_toggle_display_flag(ALLEGRO_NOFRAME) logic under Windows
as well as a bug where repeatedly setting the flag to on would make the
window grow bigger and bigger (Michael Swiger).
- Fixed inverted al_toggle_display_flag(ALLEGRO_NOFRAME) logic in X11.
- Prevent a deadlock during display creation on X.
- Fallback to the 'old' visual selection method on X instead of crashing
if the 'new' visual selection doesn't work.
Input:
- Use the same logic in set_mouse_xy for FULLSCREEN_WINDOW as was used for
FULLSCREEN. (Max OS X)
Filesystem:
- Added al_fopen_slice.
- Added al_set_exe_name which allows overriding Allegro's idea of the path
to the current executable.
- Make al_get_standard_path(ALLEGRO_TEMP_PATH) treat the value of TMPDIR
et al. as a directory name even without a trailing slash. (Unix)
- Make stdio al_fopen implementation set proper errno on failure.
Audio addons:
- Add mixer gain property and functions.
- Improve code to check that DLL symbols are loaded in the acodec addon.
The old method was hacky and broke under -O2 using GCC 4.6.1.
Image I/O addon:
- Improved accuracy of un-alpha-premultiplying in the native OSX bitmap
loader.
Primitives addon:
- Added al_draw_filled_pieslice and al_draw_pieslice.
- Added al_draw_elliptical_arc.
TTF addon:
- Added al_load_ttf_font_stretch functions (tobing).
- Added ALLEGRO_TTF_NO_AUTOHINT font loading flag to disable the Auto Hinter
which is enabled by default in newer version of FreeType (Michał Cichoń).
- Clear locked region so pixel borders aren't random garbage that can be seen
sometimes with linear filtering on.
- Unlock glyph cache page at end of text_length and get_text_dimensions
(jmasterx).
Examples:
- Added new examples: ex_audio_chain, ex_display_events, ex_file_slice.
- ex_ogre3d: Make it work under Windows (AMCerasoli).
- a5teroids: Support gamepads that report small non-zero values for sticks
that are at rest.
Other:
- Added index to HTML version of the reference manual (Jon Rafkind).
- Various documentation updates.
- Other minor bug fixes.
MD5SUMS: e973b0563fa94b27996954175210cc72 allegro-5.0.6.7z c4b4384ef03ac5f6388f378f3eeff243 allegro-5.0.6.tar.gz dc226f98c76d995e02b65e7337a4bfc9 allegro-5.0.6.zip
What's the timeframe for 5.2? Two important things there, proper iOS and Android support.
I'd like to get more Android work done before 5.2, but well, don't hold it up on my account. Two important things are likely to be sound, and apk/resource access (android provides an api to get access to the files inside the apk, an apk is just a zip, but the contents of the resource folder are never extracted, so you have to use the api, or a zip lib to access it). Also fleshing out filesystem stuff. I need to test it more.
Yeah but there should be no harm releasing it not 100% tuned. Not likely to be any deal breaker api changes so it can improve with each 5.2 release.
Well there might be breakage in the future. I've been thinking about dropping 1.6 support all together. Would simplify some stuff. Might even go so far as to not support anything older than 2.2 or even 2.3 (90%+ of all active android devices are 2.3 and above).
We told you to do that in the first place... But noooooooooo, you had to make it work on 1.6 devices... Stubborn as a mule reindeer. 
Stubborn as a mule reindeer moose.
We told you to do that in the first place... But noooooooooo, you had to make it work on 1.6 devices... Stubborn as a mule reindeer.
When I first planned things out, it was a good idea to support 1.6 
20% or more of the market was still 1.6, and more if you counted 2.0-2.2. Now its probably not worth it.
Getting this error on OS X when trying to build:
Scanning dependencies of target ex_audio_chain
[ 60%] Building CXX object examples/CMakeFiles/ex_audio_chain.dir/ex_audio_chain.cpp.o
Linking CXX executable ex_audio_chain
Undefined symbols for architecture i386:
"__al_mangled_main", referenced from:
__al_mangled_main$non_lazy_ptr in liballegro_main-static.a(osx_main.m.o)
(maybe you meant: __al_mangled_main$non_lazy_ptr)
ld: symbol(s) not found for architecture i386
collect2: ld returned 1 exit status
Undefined symbols for architecture ppc:
"__al_mangled_main", referenced from:
__al_mangled_main$non_lazy_ptr in liballegro_main-static.a(osx_main.m.o)
(maybe you meant: __al_mangled_main$non_lazy_ptr)
ld: symbol(s) not found for architecture ppc
collect2: ld returned 1 exit status
lipo: can't open input file: /var/tmp//ccrftWU3.out (No such file or directory)
make[2]: *** [examples/ex_audio_chain] Error 1
make[1]: *** [examples/CMakeFiles/ex_audio_chain.dir/all] Error 2
make: *** [all] Error 2Append: I played with the cmake options and found that if I set SHARED to ON I don't get this error. Not sure what is causing.
Also, getting all these errors when I run any A5 program now (on OS X):
2012-03-04 10:55:21.492 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x211cf0 of class NSPathStore2 autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.495 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x506510 of class NSPathStore2 autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.496 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x5066f0 of class NSConcreteMapTable autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.497 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x5066b0 of class NSCFArray autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.497 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x5065b0 of class __NSArray0 autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.498 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x5068e0 of class NSCFString autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.499 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x211f80 of class __NSFastEnumerationEnumerator autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.499 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x506d30 of class NSCFString autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.500 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x211fe0 of class __NSFastEnumerationEnumerator autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.500 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x20de10 of class NSCFNumber autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.501 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x501090 of class NSCFDictionary autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.501 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x20de10 of class NSCFNumber autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.502 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x507030 of class NSCFDictionary autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.502 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x507060 of class NSCFString autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.503 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x507080 of class NSMenuItem autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.504 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x20de10 of class NSCFNumber autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.504 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x214fe0 of class NSCFDictionary autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.505 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x5072f0 of class NSMenuItem autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.505 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x20bef0 of class NSCFNumber autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.506 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x507760 of class NSCFDictionary autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.506 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x507790 of class NSMenuItem autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.506 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x5019a0 of class NSCFNumber autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.507 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x507850 of class NSCFDictionary autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.507 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x5077d0 of class NSMenuItem autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.508 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x20c730 of class NSCFNumber autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.509 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x2150c0 of class NSCFDictionary autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.509 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x507330 of class NSCFString autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.510 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x507810 of class NSMenuItem autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.510 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x502b30 of class NSCFNumber autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.511 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x507970 of class NSCFDictionary autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.511 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x20bef0 of class NSCFNumber autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.512 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x507aa0 of class NSCFDictionary autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.512 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x20bef0 of class NSCFNumber autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.515 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x215020 of class NSCFDictionary autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.515 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x507af0 of class NSMenuItem autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.516 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x20de10 of class NSCFNumber autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.516 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x507cb0 of class NSCFDictionary autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.517 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x215070 of class NSMenuItem autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.518 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x20bef0 of class NSCFNumber autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.518 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x507d10 of class NSCFDictionary autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.519 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x507eb0 of class NSCFArray autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.519 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x508000 of class NSCFDictionary autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.520 ex_lines[63386:903] *** __NSAutoreleaseNoPool(): Object 0x507f70 of class __NSFastEnumerationEnumerator autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.534 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x50a090 of class NSCFString autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.534 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x21ac30 of class NSCFData autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.537 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x50a0e0 of class NSCFString autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.538 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x50a410 of class NSCFData autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.544 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x211250 of class NSCFString autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.545 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x20d330 of class NSConcreteValue autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.772 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x5179c0 of class NSCFString autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.773 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x231da0 of class NSCFArray autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.774 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x20c730 of class NSCFNumber autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.774 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x22ec40 of class NSCFDictionary autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.775 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0xafc30 of class NSCFString autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.776 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x5019a0 of class NSCFNumber autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.776 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x23b610 of class NSCFDictionary autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.777 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0xa007f374 of class NSCFString autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.778 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x236290 of class NSObject autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.778 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x2356a0 of class NSCFArray autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.779 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x516e70 of class NSMenuItem autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.779 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x5019a0 of class NSCFNumber autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.780 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x2357f0 of class NSCFDictionary autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.780 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x20c730 of class NSCFNumber autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.781 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x2379e0 of class NSCFDictionary autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.781 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x516950 of class NSPathStore2 autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.782 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x237550 of class NSCFData autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.782 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x518660 of class NSCFString autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.783 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x516c20 of class NSCoreUIImageRep autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.783 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x231eb0 of class NSImage autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.784 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x5065b0 of class __NSArray0 autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.784 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x237a50 of class NSImage autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.785 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x23f1e0 of class NSImage autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.785 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x20c730 of class NSCFNumber autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.785 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x5186c0 of class NSCFDictionary autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.786 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0xafc30 of class NSCFString autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.786 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x20d350 of class NSConcreteAttributedString autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.787 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x237290 of class NSConcreteAttributedString autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.787 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x22e620 of class NSConcreteAttributedString autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.788 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x22e620 of class NSConcreteAttributedString autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.788 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x22e620 of class NSConcreteAttributedString autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.789 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x5144a0 of class NSCFDictionary autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.789 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x2088f0 of class NSConcreteMutableAttributedString autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.790 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0x519050 of class NSConcreteMapTable autoreleased with no pool in place - just leaking 2012-03-04 10:55:21.790 ex_lines[63386:3d03] *** __NSAutoreleaseNoPool(): Object 0xafc30 of class NSCFString autoreleased with no pool in place - just leaking
Michał Cichoń: Tried to download from your site, but says server not found?! 
URL are fixed, try now.
Also, getting all these errors when I run any A5 program now (on OS X):
How did you compile Allegro? Which version of OSX and what kind of Mac? There's another thread about this but it doesn't happen for me so hard to debug - I'm trying to figure out how to reproduce. It's very easy to fix in any case, if you want you can just set a breakpoint to __NSAutoreleaseNoPool then create a pool before the line where gdb breaks and free it right afterwards.
I am using a Mac Mini with a Core 2 Duo and Snow Leopard (10.6.8).
I compile Allegro with the command line tools like so:
mkdir build cd build ccmake .. make
I am changing these options from the defaults from within ccmake before running 'make':
CMAKE_OSX_ARCHITECTURES i386;ppc CMAKE_OSX_DEPLOYMENT_TARGET 10.5 CMAKE_OSX_SYSROOT /Developer/SDKs/MacOSX10.5.sdk SHARED OFF WANT_EMBED OFF WANT_FLAC OFF WANT_IMAGE_JPG OFF WANT_NATIVE_IMAGE_LOADER OFF
I don't think I have support for the 10.5 sdk or for ppc here. Maybe there is a way to install them. But 32 bit is common to the other thread and I can try building for that.
The compiling problem is something to do with C++. Doesn't really have anything to do with the architecture as I've tried every combination, including the default (x86_64).
Doesn't there need to be an extern "C" somewhere for C++ code to be able to access a C function? Looking into the code (include/platform/alosx.h):
#ifndef ALLEGRO_LIB_BUILD #ifndef ALLEGRO_NO_MAGIC_MAIN #define ALLEGRO_MAGIC_MAIN #if __GNUC__ >= 4 #define main __attribute__ ((visibility("default"))) _al_mangled_main #else #define main _al_mangled_main #endif #ifdef __cplusplus extern "C" int _al_mangled_main(int, char **); #endif #endif #endif
During the build process, al_mangled_main doesn't get properly externed so any C++ programs will not find that function. This would explain the build error.
Uh, extern "C" is there. What am I missing?
#ifndef ALLEGRO_LIB_BUILD
It's there, but it doesn't get declared during the build process.
Okay. The patch that introduced the #ifndef ALLEGRO_LIB_BUILD is r14593 (r14600 on the 5.0 branch). It was included in Allegro 5.0.1.
Fix for bug #3157005 Dynamic linker can't find _al_mangled_main with XCode4
cherry-pick https://alleg.svn.sourceforge.net/svnroot/alleg/allegro/branches/5.1@14593
From: Peter Hull <peterhull90@example.org>
git-svn-id: https://alleg.svn.sourceforge.net/svnroot/alleg/allegro/branches/5.0@14600 198e8dbc-0e07-0410-9fd0-dca9db973e3e
The bug report and discussion is at http://sourceforge.net/tracker/?func=detail&aid=3157005&group_id=5665&atid=105665
I can't tell from the discussion why the ALLEGRO_LIB_BUILD bit was added.
I tried a 32-bit build with the 10.6 SDK but still everything works without warnings. I think now the problem must have to do with OSX 10.6. Some of our code which is not used under 10.7 which has no pool.
So at this point need someone who has OSX 10.6 and can run it in gdb, with a breakpoint set to __NSAutoreleaseNoPool. So basically type this:
gdb ./ex_draw_bitmaps break __NSAutoreleaseNoPool run
then when it stops type:
bt
and post the output.
#0 0x00007fff84d8cd34 in __NSAutoreleaseNoPool () #1 0x00007fff84cd7e79 in _CFAutoreleasePoolAddObject () #2 0x00007fff84cd7be6 in -[NSObject(NSObject) autorelease] () #3 0x00007fff827035ca in +[NSPathStore2 pathStoreWithCharacters:length:] () #4 0x00007fff82701a28 in -[NSString(NSPathUtilities) _stringByResolvingSymlinksInPathUsingCache:] () #5 0x00007fff82701660 in _NSLookupOrCreateBundle () #6 0x00007fff827013b4 in +[NSBundle mainBundle] () #7 0x0000000100081404 in _al_osx_run_main (argc=1, argv=0x7fff5fbff978, real_main=<value temporarily unavailable, due to optimizations>) at /Users/arvidsson/Projekt/allegro/src/macosx/osx_app_delegate.m:284 #8 0x000000010012af40 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
Mac OS X 10.6.8, Allegro 5.0.5
Not sure if you wanted the latest allegro version.
Ok, so the problem seems to be in the if() starting here: https://github.com/elias-pschernig/allegro5/blob/master/src/macosx/osx_app_delegate.m#L279
But whether I replace if with if(1) or if(0) it always works without warning here (using the SVN version).
I think I see a pattern (but may be wrong). Everyone seeing the errors is running 10.6.x? I'm on 10.7 and don't see them in my programs.
What does "TDM" stand for at MinGW 4.6.1?
Is there any special reason for not having an NSAutoreleasePool in _al_osx_run_main()?
edit: I read the commit, and apparently this just hides the memory leaks. I don't understand exactly why though.
Because then an actual leak cannot print that message any longer (since now there is a pool, just a useless one).
I get that. I don't understand why it's being useless though, but then again I'm a beginner at Cocoa.
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.
But isn't the pool drained every cycle in the event loop? Or should be at least?
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.
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.
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..
Ohhh, I see. And I was thinking about threads or something... Thanks man!.
"...al_draw_filled_pieslice and al_draw_pieslice..."
Pure pure love!
Allegro programatically makes pie?!
Allegro programatically makes pie?!
Finally I can put Pie on my vtable and feed my linked-list of children!
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.
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.
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.
I could try but I'm not sure how to go about it.
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?
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:
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.
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.
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?
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.)
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.
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.
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).
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.
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 
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.
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?
That would be excellent.