Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
DorpsGek opened this issue Aug 3, 2013 · 13 comments
Closed

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

DorpsGek opened this issue Aug 3, 2013 · 13 comments
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) OS: MacOS This issue is related to a Mac OS problem

Comments

@DorpsGek
Copy link
Member

DorpsGek commented Aug 3, 2013

ratzopaltuff opened the ticket and wrote:

- 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

Attachments

Reported version: 1.3.2
Operating system: Mac OS X


This issue was imported from FlySpray: https://bugs.openttd.org/task/5694
@DorpsGek
Copy link
Member Author

fonsinchen wrote:

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.

Attachments


This comment was imported from FlySpray: https://bugs.openttd.org/task/5694#comment12508

@DorpsGek
Copy link
Member Author

fonsinchen wrote:

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 ?? ()


This comment was imported from FlySpray: https://bugs.openttd.org/task/5694#comment12510

@DorpsGek
Copy link
Member Author

fonsinchen wrote:

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?


This comment was imported from FlySpray: https://bugs.openttd.org/task/5694#comment12511

@DorpsGek
Copy link
Member Author

fonsinchen wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5694#comment12681

@DorpsGek
Copy link
Member Author

Rubidium wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5694#comment12760

@DorpsGek
Copy link
Member Author

fonsinchen wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5694#comment12785

@DorpsGek
Copy link
Member Author

fonsinchen wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5694#comment12786

@DorpsGek
Copy link
Member Author

fonsinchen wrote:

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 flags in the Makefiles for the linker to do its job. See step 2 for the reason.

  1. 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.

  2. 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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5694#comment12791

@DorpsGek
Copy link
Member Author

DorpsGek commented Mar 1, 2014

fonsinchen wrote:

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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5694#comment13123

@DorpsGek
Copy link
Member Author

kernigh2 wrote:

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, #6069 and #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, #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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5694#comment13419

@DorpsGek
Copy link
Member Author

DorpsGek commented Aug 5, 2014

kernigh2 wrote:

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 #6069. There is no need to fix #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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5694#comment13429

@DorpsGek
Copy link
Member Author

kernigh2 wrote:

To avoid #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.


This comment was imported from FlySpray: https://bugs.openttd.org/task/5694#comment13451

@andythenorth
Copy link
Contributor

andythenorth commented Apr 12, 2018

I reckon we should run Mac OS support on a similar policy to Apple OS support. (Mac users made their choice to accept this when they went the fruit-flavoured route).

Apple's policy appears to be n-2, except for critical security vulnerabilities, which are applied further back.

Mac OS is now at 10.13, so 10.4 is very dead. PPC is also very dead.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
flyspray This issue is imported from FlySpray (https://bugs.openttd.org/) OS: MacOS This issue is related to a Mac OS problem
Projects
None yet
Development

No branches or pull requests

3 participants