BACKENDS: MacOSX - 32 bit v2.1.0 release crashes on launch on macOS 10.6.

[macca8]

On macOS 10.6.8, the 32 bit v2.1.0 release attempts to launch (loads a black screen), but crashes before it can complete the task.

The same build launches correctly on macOS 10.11.6.

Buildbot's 32 bit daily builds (developmental & stable) both launch correctly on macOS 10.6.8.

[macca8]

Crash report

[criezy]

I will need some help on that one, as the v2.1.0 32 bit release starts properly on my 10.6.8 test machine.

Unfortunately the attached crash log is not really usable as the release build does not contain debug symbols and the call stack is completely mangled.

I have prepared a build that contains the debug symbols:
​https://www.dropbox.com/s/ugk9u0t4fe8h0gl/scummvm-2.1.0-macosx-i386-nostrip.dmg?dl=0

Please can you try it and attach the resulting crash log?

[macca8]

The crash is still happening.
I see that you've removed the (unnecessary) sparkle framework from the build, which is a positive even if it doesn't affect the launch.

I've attached the debug crash log.
I haven't attached a copy of the scummvm.log, but it reports "log opened".

[macca8]

Debug crash report

[macca8]

Line 5 of the debug report has an unidentified source (???), so I tried again.
That report is still produced consistently, but I was able to get a second variation without the unidentified source (debug crash report 2), which may be more helpful.

I got the second debug report by completing a successful launch with a working build (daily stable & v2.0.0 32bit release) before trying your debug build. However, eventually crashes reverted to the original debug report.

[macca8]

debug crash report 2

[criezy]

With a working build can you please try to change the graphics mode to OpenGL, and then start the 2.1.0 release build and see if it still crashes?

[macca8]

Success!... well, sort of. The crash still exists, but I’ve been able to pinpoint the problem, if not the solution.

As you suggested, I was able to launch the app in OpenGL, and was able to identify that the problem is in operating in fullscreen mode.

I changed back to non-OpenGL (the ‘default’ setting) and disabled fullscreen mode, then quit. Upon restart, the app opened normally.

However, once launched, there’s an ongoing issue with trying to use fullscreen mode in both OpenGL & non-OpenGL graphics modes (I only tried the default setting), in either Launcher or game environments.

In OpenGL, switching to fullscreen produces a black screen, but doesn’t crash the app. Using Alt+Enter will switch back to windowed mode and normal operation.

In non-OpenGL, switching to fullscreen immediately crashes the app. In the case of changing a game’s setting to fullscreen, the crash isn’t activated until the game is launched. The debug crash reports are the same as previously advised.

It doesn’t matter whether the change to fullscreen is initiated in graphics options (global or game specific) or by using Alt+Enter (or Alt+Return).

In summary, if the Launcher is preset to fullscreen, launching the app will either present a black screen (OpenGL) or a crash (non-OpenGL).

[criezy]

Thank you for those details! That will hopefully help me pinpoint the issue. I am on the road for the next ten days without access to my build or test machines, but I wrote a big post-it to remember to look at this when I am back. So hopefully I won't forget.

[macca8]

Thanks criezy.
Actually your timing is perfect. I'm also unable to access my machine for the next 7 days. I look forward to providing any further assistance when you're back.

[macca8]

Out of curiosity, I tested the v2.1.0 32 bit intel release natively on macOS 10.5.8, and it crashes on that system as well.
Turns out the results are even more diabolical than 10.6.8... there's actually two pre-existing unresolved complications on 10.5.8 that predate the v2.1.0 release build crash.

Ignoring the release build crash, the behaviour with the current daily builds (developmental & stable) is identical to that reported for the PPC OSX v2.1.0 release build in ​https://forums.scummvm.org/viewtopic.php?f=2&t=14967#p87856, so that problem is with macOS 10.5.8 in general, not just that specific release.

The source of one of these complications is the addition of the Help Menu (no window display, no cursor (scroll to bottom of screen to reveal), Help Menu with only a search box, & the need to Force Quit (can be done from the Dock))... no crash, but the macOS console reports a problem with the Help Menu.

I was able to prove this by testing old versions. The v2.0.0 32 bit release & a daily build from June 2018 (both predating the introduction of the Help Menu) function normally on 10.5.8. A daily build from late September 2018 (featuring the Help Menu) displays the symptoms described previously (refer #11260).

The second complication is the addition of the remastered modern theme, specifically the change of the app's icon (app label accompanied by an invisible icon)... replacing the new icon with the old icon within the app's bundle resolved this issue. The obvious conflict here is the presence of 144ppi images in the new icon's file (as well as 72ppi images), whereas the old icon's file contains only 72ppi images (refer #11261).

Until these complications are resolved, it's difficult to determine if the crash with the 32 bit v2.1.0 release is the same as that affecting macOS 10.6.8.

[macca8]

New release, same problem.
The 32 bit v2.1.1 release:

• has the same fullscreen issues as v2.1.0 on macOS 10.6.8.
• crashes immediately on launch on macOS 10.5.8 (regardless of graphics modes or screen settings)... no backtrace available, but exception is SIGTRAP, and only output is Dyld error message: unknown required load command 0x80000022.
• runs perfectly on macOS 10.11.6.

On the other hand, the 32 bit v2.1.2pre375 stable build (which contains basically the same code, but a different SDL version) runs perfectly on both 10.6.8 & 10.11.6 (excluding the known SDL 1.2 bug for macOS 10.9 & later)... there are separate issues with 10.5.8 which are documented in #11260.

Clearly there's a backwards compatibility issue with the release build. Perhaps compatibility fixes introduced in August 2018 for SDK 10.9, covering all versions of macOS back to 10.5 may be a factor? Perhaps the previously stable SDL 2.0.4 (as at v2.0.0 release, and assuming it's still in use here) has been compromised by these or other changes in Scummvm's code? Or maybe there's something in the build process? Just thinking out loud...

[criezy]

I think I may have made some progress. Could you please try this new 32 bits intel version?
​https://www.dropbox.com/s/qdcyape1ulq7g4p/scummvm-2.1.2-macosx-i386.dmg?dl=0

The build targets Mac OS X 10.6, so it may not work on 10.5 but this could still be something interesting to test. But the most useful test for me would be on 10.6 to check if fullscreen works with this version or not for you.

I am using SDL 1.2.15 for the 32 bits releases, but for this one I tried using one that has been build in a way more similar to what was used before I upgraded my build environment a couple of years ago.

[macca8]

Good news. Your test build works perfectly on 10.6.8… all fullscreen issues are resolved.

Unfortunately, there’s no change on 10.5. It still crashes immediately on launch, with exactly the same error as noted in #comment:9 (and the expected invisible icon, given the target build).

On the bright side, the 32 bit v2.1.3pre0 stable build works well on 10.5, and offers the same set of features as your test build provides on 10.6.

In an unrelated issue, and I apologize for not creating a separate ticket, I did notice that the most recent 64 bit Intel Mac releases (v2.1.1 & v2.1.2) are missing the README.html & NEWS.html files in the app's Resources folder.
They’re included in both 32 & 64 bit v2.1.0 releases, and all subsequent 32bit Intel Mac releases.

[criezy]

I made a new intel 32 bit build targeting MacOS X 10.5 this time. I am not too optimistic as I suspect there might be some issues with libraries used to compile ScummVM (I had to jump through hoops to compile some of them), but I guess this is worth a try.

This new test version can be downloaded from ​https://www.dropbox.com/s/7f7mgpj9n9qbdl8/scummvm-2.1.2-macosx-i386-try2.dmg?dl=0

If that doesn't work I think I will give up trying to support 10.5 for the i386 build and bump the minimum required version to 10.6. I am quite happy with the issues on 10.6 having being fixed at least (as well as the mac PPC build).

[criezy]

Also thank you for reporting the issue about the missing README.html and NEWS.html files in the 64 bit release. The build machine was missing ​pandoc, which we use to convert the md files to html. This is now fixed, so the next release should have those html files.

[macca8]

The test build still crashes on launch on 10.5, however, there’s been some progress in identifying the source. Still no backtrace, but the crash report is now:
Dyld Error Message:

Library not loaded: /usr/lib/libcurl.4.dylib
Referenced from: …/ScummVM.app/Contents/MacOS/scummvm
Reason: Incompatible library version: scummvm requires version 6.0.0 or later, but libcurl.4.dylib provides version 5.0.0

At the end of the day, it comes down to reward for effort.

Restricting the 32 bit release to 10.6 & later would satisfy the majority of users. It would also provide consistency across all versions of macOS covered by that release, by excluding the changes required for 10.5.

Intel Mac users requiring support for 10.5 & earlier can achieve similar performance from the daily stable build, which is working on 10.5.
Perhaps a message could be posted in the Daily Builds section of the Downloads page alerting those users to its availability.

I would be in favour of the change, if that’s how you choose to proceed, in which case this ticket can be closed.

[criezy]

Thank you for the test. I was afraid that libcurl would be an issue. I could easily work around the issue by disabling the cloud feature (as I did for the PPC build), but that would be a shame for the users on 10.6. Or I could also try to use the libcurl from our daily build server (I just checked that the stable 32 bit OS X build there does have the cloud feature enabled). Since that is worth a try I am keeping this open for now until I have had the time to try that.

[somaen]

What's the status with the more recent releases for this?

[sev-]

Closing this as outdated