no-reply@allegro.cc (sleepywind) — Mon, 09 Dec 2013 19:35:28 +0000

On Mac OSX 10.9 everytime when Factorio (www.factorio.com) tries to destroy the display there comes the crash. This is only issue on that specific OS, it works fine on lower OSX versions as well as Win and Linux. The stacktrace can be found here (on the game forum): http://www.factorioforums.com/forum/viewtopic.php?f=7&t=1714 From the stack trace it looks like some sound routines are still running when destroying the display.

I am probably missing something in the destroy sequence. The destroy sequence was done mostly by trial and error mechanism:-[, so I suppose there can be plenty wrong. Here is the relevant code of the destroy sequence:

#SelectExpand
  1Display::~Display()
  2{
al_destroy_font(this->font);
this->font = NULL;
al_destroy_font(this->itemCountFont);
this->itemCountFont = NULL;
delete this->itemCountFontAgui;
this->itemCountFontAgui = NULL;
delete this->infiniteFontAgui;
this->infiniteFontAgui = NULL;
al_destroy_bitmap(this->windowIcon);
this->windowIcon = NULL;
al_shutdown_font_addon();
al_shutdown_ttf_addon();
al_shutdown_primitives_addon();
al_shutdown_image_addon();
al_uninstall_audio();
al_destroy_display(this->display);
al_uninstall_system();
 20}

and here is the relevant part from the resources allocation

#SelectExpand
this->display = al_create_display(width, height);
  2
if (!this->display)
  throw std::runtime_error("failed to create display!");
if (!al_init_image_addon())
  throw std::runtime_error("Failed to initialize al_init_image_addon!");
  7
boost::filesystem::path windowIconPath = global->paths->graphics / "factorio-icon.png";
this->windowIcon = al_load_bitmap(windowIconPath.string().c_str());
if (!this->windowIcon)
  throw std::runtime_error(ssprintf("Failed to load window icon! Loading from: %s", windowIconPath.string().c_str()));
al_set_display_icon(this->display, this->windowIcon);
al_set_window_title(this->display, ssprintf("Factorio %s", ApplicationVersion::currentVersion.str().c_str()).c_str());
if (!al_install_keyboard())
  throw std::runtime_error("failed to initialize the keyboard!");
if (!al_install_mouse())
  throw std::runtime_error("failed to initialize the mouse!");
al_init_font_addon();
if (!al_init_ttf_addon())
  throw std::runtime_error("failed to initialize the ttf addon!");
if (!al_init_primitives_addon())
  throw std::runtime_error("failed to load primitives addon!");
if (!al_install_audio())
  throw std::runtime_error("Failed to install audio!");
if (!al_init_acodec_addon())
  throw std::runtime_error("Failed to initialize audio codecs!");
if (!al_reserve_samples(50))
  throw std::runtime_error("Failed to reserve samples!");
this->loadAllegroFonts();
 30}

I played around with the OSX 10.9 machine for like an hour (I don't own one), but couldn't figure out what the problem was. I would appreciate any hints or ideas.

no-reply@allegro.cc (Edgar Reynaldo) — Tue, 10 Dec 2013 03:31:43 +0000

General recommendation for destroy ordering is FILO - first in last out. So destroy things in the reverse order you initialized them.

no-reply@allegro.cc (Peter Wang) — Tue, 10 Dec 2013 14:00:42 +0000

Since you shut down Allegro in a destructor you might want to ensure that the destructor is really only run when appropriate.

It could well be a bug in Allegro (if so, please fix). You might try not shutting down the addons individually and letting al_uninstall_system take care of it. al_uninstall_system is not strictly necessary either.

crash on destroy_display in OSX 10.9