OpenTTD

Tasklist

FS#5694 - Crash: [OSX] crash/freeze on openttd startup

Attached to Project: OpenTTD
Opened by Shlomo U. Rynsteen (ratzopaltuff) - Saturday, 03 August 2013, 19:52 GMT
Last edited by andythenorth (andythenorth) - Tuesday, 22 August 2017, 06:53 GMT
Type Bug
Category Build system
Status Confirmed
Assigned To No-one
Operating System Mac OS X
Severity High
Priority High
Reported Version 1.3.2
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

- log, sav and png attached
- used system: macosx 10.4.11, ppc-g3

- 1.3.1 works well
- when started in fullscreen mode crash/freeze blocks the use of os-gui
This task depends upon

2017-08-15: A task closure has been requested. Reason for request: I recommend that for OS X / macOS we take a similar approach to Apple and only 'n, n-1, n-2'. As OpenTTD has no macOS maintainer, the ability to provide support is in any case limited. As a macOS user I try and reproduce OS X / macOS bugs, and help others test fixes, but I can't diagnose the causes or provide patches myself. I am aware that this offers nothing to those who are stuck with older OS/hardware combinations (or who are tinkering), but I think it's better to be explicit about support and avoid disappointment.
Comment by fonsinchen (fonsinchen) - Saturday, 10 August 2013, 13:08 GMT
I did some experiments:

1. I can reproduce most of the problem with my Ibook G4 with OSX 10.4. It cleanly crashes and doesn't block the GUI here, but it produces the same crash log.

2. When trying with a trunk r25703 built by the compile farm it crashes even earlier, giving only a "bus error"

3. When building trunk on that system myself, I run into various problems. See r25606 to r25614 for fixes to them. When running the resulting binary it works fine.

4. When building 1.3.2 on that system, I run into some of the above problems and some additional ones. The hotkey system triggers a compiler bug, resulting in an "internal compiler error", which can be worked around by moving some OnKeyPress() implementations out of the class declarations. See hotkeys.diff about that. Additionally 1.3.2 needs some treatment to avoid erroneously defining HAVE_NON_CONST_ICONV if MAC_OS_X_VERSION_10_5 is not present. See defines.diff about that. The problems causing compile errors which are present in both trunk and 1.3.2 are the ones fixed by r25706 and r25712. After fixing all that 1.3.2 also runs fine.

I have built with --enable-debug=3 in all cases I built myself.
Comment by fonsinchen (fonsinchen) - Sunday, 11 August 2013, 09:28 GMT
CF-built r25716 still doesn't work. Surprisingly I can get somewhat meaningful backtraces from those crashes.
For r25716:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x0032e328 in IcuStringIterator::SetString ()
(gdb) bt
#0 0x0032e328 in IcuStringIterator::SetString ()
#1 0x0033cf78 in Textbuf::UpdateStringIter ()
#2 0x00d8bed8 in __static_initialization_and_destruction_0 ()
#3 0x8fe15670 in __dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE ()
#4 0x8fe0babc in __dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextE ()
#5 0x8fe0d604 in __dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextE ()
#6 0x8fe02cb4 in __dyld__ZN4dyld24initializeMainExecutableEv ()
#7 0x00002de4 in _start ()
#8 0x00002cb0 in start ()

And for 1.3.2:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000000
0x004a38e4 in non-virtual thunk to icu_51::LEGlyphStorage::applyInsertion(int, int, unsigned int*) ()
(gdb) bt
#0 0x004a38e4 in non-virtual thunk to icu_51::LEGlyphStorage::applyInsertion(int, int, unsigned int*) ()
#1 0x004a38c8 in non-virtual thunk to icu_51::LEGlyphStorage::applyInsertion(int, int, unsigned int*) ()
warning: Previous frame identical to this frame (corrupt stack?)
#2 0x004a55e4 in non-virtual thunk to icu_51::LEGlyphStorage::applyInsertion(int, int, unsigned int*) ()
#3 0x0011568c in CreateScenarioWindow::OnPaint ()
#4 0x001107bc in CreateScenarioWindow::OnPaint ()
#5 0x00110940 in CreateScenarioWindow::OnPaint ()
#6 0x00328648 in WaypointWindow::OnResize ()
#7 0x00329890 in WaypointWindow::OnResize ()
#8 0x00334a90 in DropdownWindow::OnMouseLoop ()
#9 0x00334b60 in DropdownWindow::OnMouseLoop ()
#10 0x0014225c in IniFile::~IniFile ()
#11 0x0010c1e8 in LanguageScanner::AddFile ()
#12 0x001d1c78 in BuildObjectWindow::OnClick ()
#13 0x001e0c68 in CrashLogOSX::~CrashLogOSX ()
#14 0x000021bc in ?? ()
#15 0x00001ec0 in ?? ()


Comment by fonsinchen (fonsinchen) - Sunday, 11 August 2013, 09:49 GMT
Well, if I build myself it says "checking libicu... not found" on ./configure. This seems to be the relevant difference. libicu seems to be statically linked in but somehow incompatible to Mac OS 10.4. What about building a version --without-icu on the compile farm? What does "otool -L libicu.a" say on the compile farm?
Comment by fonsinchen (fonsinchen) - Saturday, 12 October 2013, 10:00 GMT
The build farm seems to have a broken binary of ICU for OSX/PPC. I can't change the build farm, but again I suggest just building the PPC version without ICU. I tried to build a clean version of ICU on my Ibook G4 and failed miserably. It seems the ICU people don't really support OSX/PPC. As that is a pretty old platform anyway not having all the bells and whistles of internationalization available there won't kill us.
Comment by Remko Bijker (Rubidium) - Thursday, 14 November 2013, 19:07 GMT
Having one version without ICU and one with ICU can't be easily done, except not having an universal binary anymore. Unless you want to hardcode all kinds of code into the configure script at all kinds of stages to prevent it from adding it to CFLAGS and linking to it.
Comment by fonsinchen (fonsinchen) - Saturday, 16 November 2013, 18:54 GMT
http://devs.openttd.org/~fonsinchen/icu.tar.gz is a build of ICU for PPC compiled on my machine. After some fiddling with linker paths and actually editing the .dylib binaries to point to the right files openttd does link against it and doesn't immediately crash. It does crash when I open the Online Content window, though. I don't know if that's a regression somehow caused by ICU or an unrelated problem. Due to the slowness of that machine it'll take me a while to figure that out.
Comment by fonsinchen (fonsinchen) - Saturday, 16 November 2013, 19:28 GMT
The content window also crashes if compiled --without-icu. I'll post a separate bug for that. The ICU build seems OK and we might want to use it for the compile farm.
Comment by fonsinchen (fonsinchen) - Sunday, 17 November 2013, 12:17 GMT
I've updated the build to also provide statically linkable libraries. So here is what I did to produce this package:

1. Build ICU 51.2 in a separate directory with this configuration:

../source/configure --host=powerpc-apple-darwin8 --disable-samples --disable-tests --disable-tools --enable-shared --enable-static --prefix=/usr/local --bindir=/usr/local/bin CFLAGS="-O2 -D__DARWIN_UNIX03=0 -D__XOPEN_SOURCE=400 -fpermissive" CXXFLAGS="-O2 -D__DARWIN_UNIX03=0 -D__XOPEN_SOURCE=400 -fpermissive"

Most of the options are taken from michi_cc's ICU build script at http://www.icosahedron.de/openttd/patches/build_icu_osx.sh, but as my compiler is considerably older than his, I had to drop the universal binary support and -mmacosx-version-min and I decided to put it in /usr/local as that seemed the most appropriate place on my system. -fpermissive is necessary for my compiler (gcc 4.0) to accept the ICU code. It spits out a lot of warnings during the compilation, but most of those are because -fpermissive is only allowed for C++ compilation. During the linking step, I changed the order of -licu<thing> flags in the Makefiles for the linker to do its job. See step 2 for the reason.

2. Edit libicudata.51.2.dylib with a hex editor to point to "libicudata.51.dylib" instead of "../lib/libicudata.51.2.dylib". Like that it looks just like the other ICU libraries. The files are the same anyway, due to symbolic links, but the linker obviously has problems resolving relative paths in dynamically linked libraries. This enables dynamic linking of openttd to icu with plain ./configure.

3. Make a copy of each libicu*.a file, called libsicu*.a, and run those through ranlib. This enables static linking of openttd to icu with the --static-icu flag for openttd's configure.
Comment by fonsinchen (fonsinchen) - Saturday, 01 March 2014, 13:49 GMT
We should really do something about this. Linking ICU dynamically instead of statically would fix it. Just dropping support for PowerPC would be another option.
Comment by George Koehler (kernigh2) - Monday, 28 July 2014, 20:40 GMT
I was playing SimCity 2000 on a PowerBook G4 with Mac OS X 10.4.11, but I went bankrupt after building too many rails and rail stations. Then I found OpenTTD and downloaded the Mac version of OpenTTD 1.4.1. I opened it, and its icon bounced on the dock and then disappeared. The game would not start. I then wasted time by downloading OpenGFX, OpenSFX and OpenMSX and trying to install them, but that was not the problem. I deleted these downloads from my Mac, went to my OpenBSD machine, ran `pkg_add openttd` as root, and started playing OpenTTD 1.3.3 for OpenBSD.

A few days ago, I went back to the Mac and tried again with OpenTTD 1.4.2-RC1. Again, the icon bounced and disappeared. I did not find any crash.* files. This time, I ran the game through gdb and got the backtrace with IcuStringIterator::SetString, like the one fonsinchen posted in August 2013. So here is my bug.

Then I decided to build my own binary. I had built OpenTTD 1.4.2-RC1 for OpenBSD, and chose to build OpenTTD 1.4.1 for Mac. First, I needed to build the dependencies. OpenBSD has packages for the dependencies, but Mac does not. I had already installed and bootstrapped pkgsrc for Mac, so I used pkgsrc to build the dependencies. While building ICU 53.1, I hit ICU ticket #9367 (http://bugs.icu-project.org/trac/ticket/9367). I modified ICU and attached my patch, icu-for-tiger.diff, to the ICU ticket.

I then used pkgsrc to build OpenTTD. It would build OpenTTD 1.3.2, but I modified pkgsrc to build OpenTTD 1.4.1. During this build, I got errors. I reported two new bugs for these,  FS#6069  and  FS#6070 , and attached my patches to them. Then I finished the build, and it worked! The game started. I have this one problem where the "Find Servers" button in Multiplayer never finds any servers, but everything else seems to work. I can play the single-player game on my Mac, and I can download online content.

I can't explain this bug, FS#5694, because the bug went away when I made my own build. I might redo the build outside of pkgsrc, and check if this bug (the crash in IcuStringIterator::SetString) comes back.
Comment by George Koehler (kernigh2) - Tuesday, 05 August 2014, 00:18 GMT
I confirm that the openttd.org binary of OpenTTD 1.4.1-RC2 crashes on startup with my PowerPC Mac OS X 10.4.11. However, I can't reproduce this bug if I build my own binary.

This time, I built everything manually, without pkgsrc. I made no modifications to OpenTTD or any of its dependencies except ICU. I applied my icu-for-tiger.diff (from http://bugs.icu-project.org/trac/ticket/9367) to ICU. OpenTTD 1.4.1-RC2 now includes the fix for  FS#6069 . There is no need to fix  FS#6070 , a bug in pkgsrc that I mistakingly reported here.

I used these files: pkg-config-0.28.tar.gz xz-5.0.5.tar.bz2 libpng-1.6.12.tar.xz lzo-2.08.tar.gz freetype-2.5.3.tar.bz2 icu4c-53_1-src.tgz openttd-1.4.2-RC2-source.tar.xz

I built them in that order. Other orders might work, but pkg-config and libpng should go before freetype (because freetype can optionally use libpng), and openttd must go after everything else. It is convenient to build xz early and use its xzcat to extract .tar.xz files. I only built static libraries. I installed libraries into ~/park/static and put ~/park/static/bin in my PATH so *-config programs get found.

I used these configurations:

# in pkg-config-0.28/
./configure --prefix=$HOME/park/static --with-internal-glib
# in xz-5.0.5/
./configure --prefix=$HOME/park/static --disable-shared
# in libpng-1.6.12/
./configure --prefix=$HOME/park/static --disable-shared
# in lzo-2.08/
./configure --prefix=$HOME/park/static --disable-shared
# in freetype-2.5.3/
./configure --prefix=$HOME/park/static --disable-shared
# in icu/source/
patch < icu-for-tiger.diff
./configure --prefix=$HOME/park/static --disable-shared --enable-static
# in openttd-1.4.2-RC2/
./configure --with-lzo2=$HOME/park/static/lib

After configuring each library, I did "make" and "make install" before doing the next library. After configuring OpenTTD, I did "make" and started the game through "bin/openttd"; I was too lazy to "make bundle". I noticed some graphical glitches, but I did start the game, download OpenGFX, and build a train.

I did not use any SDKs from /Developer/SDKs, and I did not do a Universal build; this was just a simple build for my PowerPC 10.4.11 system. I did not need any of the extra steps that fonsinchen used to build ICU 51.2 in November 2013; I did not pass custom CFLAGS, nor use a hex editor, nor copy any files to libsicu*.a.
Comment by George Koehler (kernigh2) - Friday, 15 August 2014, 22:22 GMT
To avoid FS#6087, I am adding --disable-cocoa-quickdraw to my configure line:

# in openttd-1.4.2-RC2/
./configure --with-lzo2=$HOME/park/static/lib --disable-cocoa-quickdraw

I recommend that anyone who wants to compile a binary that might run on OS X 10.4 should use --disable-cocoa-quickdraw.

Loading...