The article linked above points out the specific bug the Apple code, which causes programs to terminate when certain conditions it controls are encountered. When compiled with earlier versions of the C++ language, this was not absolutely a bug, but certainly an unwise coding practice that risked becoming a bug like this, if called in the wrong circumstances. The update to C++ means that this becomes a bug that kills your application no matter the circumstances (if the specific test fails).
That article is over two months old, and I have not heard of Apple fixing their bug yet. There may not be much BeamDog can do, other than wait and see. It might be possible to avoid the situation that causes this problem arising in the first place, but finding and changing working code, to just work differently to avoid this kind of problem is much harder than Apple's job of fixing the original problem (add the text 'noexcept(false)' in one, at most two lines, of their entire code-base, unless there are more such bugs to be fixed - oh, and then recompile and issue an update to your library/operating-system).
Note that just because the Apple code is now compiled with a more recent version of the C++ language does not mean that the BeamDog code is compiled with the latest and greatest. There could be a separate task to update all of that code, which could easily be anything from a 5-minute to 3-month-or-more task, depending on how frequently the code base (whose origins predate the original C++ standard) uses coding patterns that changed meaning in the language update. Luckily, most of those changes cause the code to fail to compile, rather than run with a different (incompatible) meaning.
So basically, the most productive way to fix this is out of BeamDog's hands. They could try to bring pressure to bear on Apple, but I doubt there is much leverage there, and even then the solution would be for customers to update to a version of El Capitan that has the fix.
@scient our best guys (not me) are on it, and they did spot that it was an OpenAL issue during our quiet period there. We weren't ignoring y'all, we were busily chasing the issue down.
Now all the relevant details have been filtered up to the decision makers to determine when & how this will be fixed, QA'd and released.
@Cerevant posted this 4 months ago. Beamdog obviously know how to fix the bug. Hopefully the fix is included in the upcoming 1.4 version of the game engine for BGEE.
I very much appreciate the information that this thread provided. I was having the same CTD at several transition points, most recently while trying to enter Baldur's Gate. The Ambient Sound selection solved the issue. Thank you!
I very much appreciate the information that this thread provided. I was having the same CTD at several transition points, most recently while trying to enter Baldur's Gate. The Ambient Sound selection solved the issue. Thank you!
Same here. Thanks very much to those of you who've diagnosed the problem, and particularly to lava for the temporary (hopefully) workaround.
Comments
That article is over two months old, and I have not heard of Apple fixing their bug yet. There may not be much BeamDog can do, other than wait and see. It might be possible to avoid the situation that causes this problem arising in the first place, but finding and changing working code, to just work differently to avoid this kind of problem is much harder than Apple's job of fixing the original problem (add the text 'noexcept(false)' in one, at most two lines, of their entire code-base, unless there are more such bugs to be fixed - oh, and then recompile and issue an update to your library/operating-system).
Note that just because the Apple code is now compiled with a more recent version of the C++ language does not mean that the BeamDog code is compiled with the latest and greatest. There could be a separate task to update all of that code, which could easily be anything from a 5-minute to 3-month-or-more task, depending on how frequently the code base (whose origins predate the original C++ standard) uses coding patterns that changed meaning in the language update. Luckily, most of those changes cause the code to fail to compile, rather than run with a different (incompatible) meaning.
So basically, the most productive way to fix this is out of BeamDog's hands. They could try to bring pressure to bear on Apple, but I doubt there is much leverage there, and even then the solution would be for customers to update to a version of El Capitan that has the fix.
Good news.