Rubidium wrote:

Given the crash log, it's a floating point error. This is usually division by zero. There are two divisions in the function that crashes.

One divides a number by the list length, another by the average height. The average height is the list height divided by the list length, so it looks to me like the OS X specific parts of OpenTTD do not fill the drop down data correctly.

One big caveat is that there is effectively no active OS X developer, so it might take a long time for anyone attempting to fix this bug.

This comment was imported from FlySpray: https://bugs.openttd.org/task/6012#comment13311

willglynn wrote:

I'm toying with this a bit but I feel like I'm missing some development infrastructure. (There's no XCode project and make-via-XCode isn't playing nice with my Homebrew-supplied LZMA/LZO libraries.) How are the current OSX binaries produced?

This comment was imported from FlySpray: https://bugs.openttd.org/task/6012#comment13321

willglynn wrote:

I got it built and running in a debugger. My binary doesn't crash.

Attachments

• Screen Shot 2014-05-12 at 11.28.14 AM.png (529.50 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/6012#comment13322

willglynn wrote:

I can report that the latest prebuilt nightly (openttd-trunk-r26585-macosx-universal) also does not crash. I'm traveling in the morning and don't really have time to bisect this tonight, but I thought that worth noting.

This comment was imported from FlySpray: https://bugs.openttd.org/task/6012#comment13324

frosch wrote:

#6020 reports this issue for 1.4.0

This comment was imported from FlySpray: https://bugs.openttd.org/task/6012#comment13331

fonsinchen wrote:

This seems similar to #5889 and, surprisingly, #5885. #5885 is also a division by 0, at a similar place, from a dropdown list, caused by bad font selection that makes the height of the entries 0.

This comment was imported from FlySpray: https://bugs.openttd.org/task/6012#comment13333

ChooChoo5 wrote:

With V1.4.0, running on OS X 10.6.8, as well as this issue, the 'fullscreen' button does not function - the error 'fullscreen mode failed' appears.

This comment was imported from FlySpray: https://bugs.openttd.org/task/6012#comment13339

willglynn wrote:

I just downloaded the openttd-1.4.1-RC2-macosx-universal and openttd-trunk-r26620-macosx-universal builds. 1.4.1-RC2 has this crash bug, r26620 does not.

This comment was imported from FlySpray: https://bugs.openttd.org/task/6012#comment13354

willglynn wrote:

The crash is at: http://vcs.openttd.org/svn/browser/branches/1.4/src/widgets/dropdown.cpp# L144
invoked from: http://vcs.openttd.org/svn/browser/branches/1.4/src/settings_gui.cpp# L442

_num_resolutions is 0 by the time we get here. The Allegro driver guards against this so it seems like a legal (but uncommon) condition which should not result in the game crashing.

Poking around further, QZ_UpdateVideoModes() gets called twice on startup: I get 13 modes the first time and 0 the second. The first call is from VideoDriver_Cocoa::Start(), the second from VideoDriver_Cocoa::ChangeResolution(). I don't know why it's failing (or why trunk works fine) but it seems reasonable to use the existing resolution list if subsequent calls are empty, so that's what this patch does. This fixes the issue although, again, the game should probably not crash if _num_resolutions is 0 for any other reason.

Attachments

• refuse_to_empty_resolution_list.diff (0.88 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/6012#comment13355

willglynn wrote:

As expected, openttd-1.4.1-macosx-universal has this crash bug.

A little more digging: QZ_ListModes() is first called with device_depth=32, then called again with device_depth=8. OSX returns no resolutions at 8bpp, so QZ_ListModes returns an empty set. I don't claim to understand the graphics code (especially since the OSX bits use way-deprecated APIs) but I still think my patch is a reasonable workaround.

This comment was imported from FlySpray: https://bugs.openttd.org/task/6012#comment13356

fonsinchen wrote:

Some OS don't do 8bpp anymore. Apparently the game is running in some supported video mode when you click on the dropdown, or else you wouldn't see anything at all. Probably that is a 32bpp mode. The bug is then that the wrong pixel depth is given to the query to retrieve the list of resolutions. Or, more generally, we need a way to cleanly sort out the 8bpp vs. 32bpp mess when switching video modes. Currently the chosen mode depends on various factors: the user's choice, the modes supported by OS and driver, pixel depth of loaded base sets and pixel depth of loaded newgrfs, off the top of my head. Those things can change independent of each other at runtime, leading to new modes being chosen. The result probably feels pretty chaotic to anyone not really involved in that and under certain conditions it can just fail to choose the right mode.

This comment was imported from FlySpray: https://bugs.openttd.org/task/6012#comment13358

frosch wrote:

Trunk always uses 32bpp since r26522. 8bpp is only used when enabled via a config-file-only option. That may be, why this seems to only apply to 1.4.

There is also an option to use 32bpp specifically only for full screen, which is used in the win32 video driver (win32_v.cpp:288).

So, I guess the fix should be:
- Do not crash for empty list, but display an error.
- If it is worth the effort, make the osx video driver behave like the win32 driver.

(just in case: r26522 won't make it into the 1.4 branch)

This comment was imported from FlySpray: https://bugs.openttd.org/task/6012#comment13359

willglynn wrote:

It certainly does feel chaotic.

I note that QZ_CanDisplay8bpp() says:

/* 8bpp modes are deprecated starting in 10.5. CoreGraphics will return them

• as available in the display list, but many features (e.g. palette animation)
• will be broken. */
  if (MacOSVersionIsAtLeast(10, 5, 0)) return false;

My Mac (running 10.9) doesn't list any 8bpp modes, so the resolution list is empty, and clicking it causes a crash-to-desktop. This can be reproduced 100% of the time and should be fixed somehow.

Relatedly: is there an official position about support for ancient versions of OSX? The game has code for 10.3 (over 10 years old) and build support for universal binaries (PowerPC Macs haven't been sold in 8 years, Rosetta was removed 3 years ago). It links against Carbon, which is 32-bit only and deprecated entirely as of 10.8. It's my opinion that the OSX port needs modernizing but I don't have any inclination to try if supporting way past end-of-life Apple targets is a requirement.

The most recent changelog entry that dropped support for something OSX-related was 8 years ago:

0.5.0-RC2 (2006-12-31)
------------------------------------------------------------------------
- General Removed support for OSX older than 10.3.9. Either upgrade, or use 0.4.8 (compatible with OSX 10.2)

10.3.9 was released April 15, 2005, 625 days prior.

This comment was imported from FlySpray: https://bugs.openttd.org/task/6012#comment13360

planetmaker wrote:

The crash with a zero-length resolution list surely needs to be fixed, independent of a long-needed update of the OSX port.

And agreed, the OSX port grew quite a bit chaotic and is a bit in a state of negligience. If you're prepared to take a sound stab at issues and walk that stony path, that will be very welcome indeed! We talked a bit in # openttd.dev and can probably agree to remove support for some ancient OSX versions meanwhile - they are really ancient. (Even my ancient laptop runs meanwhile 10.6 which isn't new anymore either and already unsupported). Alternatively, or additionally we might also provide different OSX builds for different OSX versions, if needed.
If possible, please make it small steps so that it can be followed and reviewed somewhat :)

Alas, there's one very big stumbling stone with upping the SDK we use: our compile farm. That will need updating or rather re-creation at the same time or we're left without any builds at all: our OSX builds are created by a linux-to-OSX cross-compiler: http://devs.openttd.org/~truebrain/compile-farm/apple-darwin9.txt
An alternative might be, to get a native OSX instance which we have root access to so that a bamboo build node can be installed on it. But prices for those are usually way out-of-proportion compared to our total server hosting costs, so that it's very hard to justify that expense.

This comment was imported from FlySpray: https://bugs.openttd.org/task/6012#comment13361

fonsinchen wrote:

It might be appropriate to have two video drivers for Mac OS, targetting different APIs. Like that we could keep support for older versions around while not preventing support for new versions.

This comment was imported from FlySpray: https://bugs.openttd.org/task/6012#comment13362

willglynn wrote:

Well, I do know that Travis-CI has OSX support: http://blog.travis-ci.com/2014-05-13-multi-os-feature-available/

Travis is free for open-source projects, though I'm not sure how best to hook it into the OpenTTD build infrastructure – I've only ever used Travis with GitHub projects. Still, it's definitely possible to get access to actual OSX machines, compile stuff, and ship out build artifacts without having a dedicated server.

While I'm here, I'll ask an even more inflammatory question: is the build process negotiable? I would love to use CMake to generate build scripts appropriate for each platform (Makefiles, build.ninja, Visual Studio projects, Xcode projects, etc.) in part because it would make my life better (i.e. keeping multiple out-of-tree builds with different settings).

This comment was imported from FlySpray: https://bugs.openttd.org/task/6012#comment13363

willglynn wrote:

I got CMake generating an Xcode project on my machine. It seems to work, including settingsgen/strgen. The CMake Makefile and ninja generators work too, all building from the same source tree. And, of course, once the Makefile/ninja/Xcode project is created, it'll regenerate itself automatically as CMakeLists.txt changes. My CMake setup doesn't have all the smarts of config.lib at this time – in particular it doesn't set the proper compile-time flags on platforms other than OSX – but that can be added if desired.

I found that some of the things that seemed complicated before were easy to re-do. Take endianness for example. CMake's include(TestBigEndian) / test_big_endian() does what you think, but better than you might expect: it builds a program with two constant uint16 arrays and greps the resulting binary for the test patterns. While OpenTTD's endianness determination relies on being able to run an executable, CMake's standard test relies only on being able to compile it, thus determining target endianness reliably even when it differs from the host.

One of the features enabled by having a normal Xcode project is the ability to click a button and run the whole project through the Clang static analyzer. Sure enough, it found this crash bug.

Attachments

• Screen Shot 2014-06-05 at 8.59.33 AM.png (318.36 KiB)
• Screen Shot 2014-06-05 at 8.53.19 AM.png (361.84 KiB)

This comment was imported from FlySpray: https://bugs.openttd.org/task/6012#comment13364

frosch wrote:

The original issue (the crash) has been fixed in r26629 in an back-portable way.

There seeem to be some other topics in this task:
* OSX not supporting 8bpp modes -> 1.5 will address that by disabling 8bpp by default. 1.4 will get the error message from r26629. I don't think it's worth the effort to bother more about 8bpp on OSX.
* New OSX video drivers for this year's API. Maybe join IRC and directly discuss this matter with planetmaker and fonsinchen.
* Using cmake instead of configure. This sounds like it will heavily affect openttd.org's compile farm, infrastructure, releases and OS distributions. I don't see anyone having the time in the near future to deal with all this hassle, esp. since the current system works.

This comment was imported from FlySpray: https://bugs.openttd.org/task/6012#comment13368

frosch closed the ticket.

Reason for closing: Fixed

in r26629

This comment was imported from FlySpray: https://bugs.openttd.org/task/6012

planetmaker wrote:

While IRC might make some discussions easier, alternatively create a new issue (or issues as needed) here for the rework of the OSX video drivers.
As to cmake: that changes many things and breaks it for many people, so it's not something to consider lightly. What could be done much easier, is adding an XCode project file similar to the MSVC project files. But it shouldn't change for each commit and be rather universal for XCode than special to your setup.

This comment was imported from FlySpray: https://bugs.openttd.org/task/6012#comment13369