[Mac] Nightlies crash on start

Have you tried reverting to factory settings through Terminal? See https://musescore.org/en/handbook/revert-factory-settings#instructions-….

I have the same problem.

Mac 10.11.6 - I don't know if it affects other operating systems (above 10.9?).

There may be different issues involved here. The very recent nightly builds are reported to crash on Mac and the culprit seems to be 0b1aea9.
See also http://dev-list.musescore.org/Heads-up-an-array-of-structs-initialisati…
The crash Ron Cohen experienced got to be different though

I share the same crash as Ron.

I pushed a quick fix in eb4455ca1f
Can someone confirm that the nightly starts?

As far as I understand Ron Cohen and chen lung are having a different crash?
Anyway, we know more when they checked ;-)

lasconic: Thanks for the commit, but it doesn't work for me.

Jojo: I said it's the same because Ron and I seem to have the same log.

Came up again in https://musescore.org/en/node/164331

Can someone confirm that it's also the case for 2.1 nightlies?

4a34643 opens fine for me.

libvorbisfile.3.dylib doesn't reference correctly libvorbis and I don't know why.
In 2.1 branch it works correctly and in master it doesn't. I believe it's the job of macdeployqt to fix the reference and I guess the Qt 5.6 version doesn't do while the Qt 5.4 version does it... We could try with Qt 5.8 as a soon as it's released.

It would be great to know where it started to stop working, maybe when we changed to Qt 5.6.2. 3 months ago... https://github.com/musescore/MuseScore/commit/9716e70d7e1f02124192d1414…

Hmm, that change was mid october, the report here says ... just fine ... MuseScoreNightly-2016-11-14-1527-master-2eb7be1 (2eb7be1), from mid-November and the problem starting with 53d4ad2, and c65ab20

It's not that. The oldest version currently available from http://prereleases.musescore.org/macosx/nightly/, 5569b5d from January 2, opens just fine for me. I can probably do a cadiz1 and narrow down exactly which nightly fails.

Please do, as far as I know cadiz1 is not on a Mac.
OTOH Ron Cohen reported the issue 22-Dec-2016, seems to contradict your 2-Jan-2017?

Hmm, quite probably a different cause, then. I have no clue how to read a crash log, but if you do, my version of this issue looks like this:

so nothing about libvorbis not getting loaded?

Got it, its 0b1aea9 (like you said above).

libvorbis is mentioned a few times, but as far as I can tell not in the context of reporting an error.

Well, that issue from 0b1aea9 should be fixed meanwhile.
So apparently you're not seeing the same issue as Ron Cohen and chen lung

I don't think it has been fixed. 73a2e6a opens, 0b1aea9 does not, and everything since then up through e4f8671 also does not.

Ah, I see, I misunderstood your #14

Yes, 4a34643 (2.1) has no problems. ;-)

I understood that 2.1 works for you, but thought that means master works too. That's apparently not the case

Correct.

I managed to reproduce the problem and I compared a 3.0-dev Nightly and a 2.1-dev Nightly; only the 3.0-dev Nightly crashed at startup.
I am attaching the "otool -L" log of the two applications, and of the problematic libraries.
In particular, for [...]/Frameworks/libvorbisfile.3.dylib we have:
for 3.0-dev:
./libvorbisfile.3.dylib:
@executable_path/../Frameworks/libvorbisfile.3.dylib (compatibility version 7.0.0, current version 7.7.0)
/usr/local/Cellar/libvorbis/1.3.5/lib/libvorbis.0.dylib (compatibility version 5.0.0, current version 5.8.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
@executable_path/../Frameworks/libogg.0.dylib (compatibility version 9.0.0, current version 9.2.0)
for 2.1-dev:
./libvorbisfile.3.dylib:
@executable_path/../Frameworks/libvorbisfile.3.dylib (compatibility version 7.0.0, current version 7.7.0)
@executable_path/../Frameworks/libvorbis.0.dylib (compatibility version 5.0.0, current version 5.8.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)
@executable_path/../Frameworks/libogg.0.dylib (compatibility version 9.0.0, current version 9.2.0)

So I think that the problem is not in MuseScore itself, but in the dylib library which is included at packaging time.
Do the 3.0-dev and 2.1-dev share the same Homebrew and Mac OS versions?

I tried to force more output from the build log:
https://travis-ci.org/AntonioBL/MuseScore/jobs/193789746

It seems that macdeployqt is searching the libraries in folder /usr/local/opt/
Indeed in the log we have:

Log: copied: "/usr/local/opt/libvorbis/lib/libvorbisfile.3.dylib"
Log: to "/Volumes/MuseScoreNightly-macprova-fbc1004/mscore.app/Contents/Frameworks//libvorbisfile.3.dylib"

But then inside some of the libraries (and libvorbisfile.3.dylib) there are references to libraries in another folder: /usr/local/Cellar
For example the log says:

Log: Using otool:
Log: inspecting "/usr/local/Cellar/libvorbis/1.3.5/lib/libvorbis.0.dylib"
when analyzing the dependencies of /usr/local/opt/libvorbis/lib/libvorbisfile.3.dylib

Then only the libraries beginning with path /usr/local/opt/ are properly patched. In the example, the deploy tool tries to patch /usr/local/opt/libvorbis/lib/libvorbis.0.dylib, but this reference does not exist inside libvorbisfile.3.dylib:

Log: change reference "/usr/local/opt/libvorbis/lib/libvorbis.0.dylib"
Log: to "@executable_path/../Frameworks/libvorbis.0.dylib"

In summary I think there could be a problem in macdeployqt or a possible mismatch in Homebrew installation, but in this latter case we would see the same also for 2.1-dev.
It would be interesting to see a verbose macdeployqt also for 2.1-dev (here what I added to see the log: https://github.com/AntonioBL/MuseScore/commit/fbc1004f9f6b ).

I hope this analysis helps in solving the problem. In attachment to this post the macdeployqt log file.

And finally I found what is actually happening.
See here:
https://bugreports.qt.io/browse/QTBUG-56814

The fault seems to be 50% Qt and 50% Homebrew: in Homebrew libraries, the install name inside the library points to a symlink "/usr/local/opt/[...]", and the actual library is in "/usr/local/Cellar/[...]". Inside Homebrew libraries, other libraries are referred to with their absolute path, i.e. "/usr/local/Cellar/[...]". Macdeployqt replaces inside the deployed libraries the "install name" with a reference to the bundled framework, and as seen in the above comment this does not work because in the dylib it is stored the actual absolute path to the library.

Indeed, from the macdeployqt log of 3.0-dev and 2.1-dev we have:

2.1-dev
Log: Adding framework:
Log: Framework name "libvorbis.0.dylib"
Framework directory "/usr/local/Cellar/libvorbis/1.3.5/lib/"
Framework path "/usr/local/Cellar/libvorbis/1.3.5/lib/libvorbis.0.dylib"
Binary directory "/usr/local/Cellar/libvorbis/1.3.5/lib/"
Binary name "libvorbis.0.dylib"
Binary path "/usr/local/Cellar/libvorbis/1.3.5/lib/libvorbis.0.dylib"
Version ""
Install name "/usr/local/Cellar/libvorbis/1.3.5/lib/libvorbis.0.dylib"
Deployed install name "@executable_path/../Frameworks/libvorbis.0.dylib"
Source file Path "/usr/local/Cellar/libvorbis/1.3.5/lib/libvorbis.0.dylib"
Framework Destination Directory (relative to bundle) "Contents/Frameworks/"
Binary Destination Directory (relative to bundle) "Contents/Frameworks/"



3.0-dev
Log: Adding framework:
Log: Framework name "libvorbis.0.dylib"
Framework directory "/usr/local/Cellar/libvorbis/1.3.5/lib/"
Framework path "/usr/local/Cellar/libvorbis/1.3.5/lib/libvorbis.0.dylib"
Binary directory "/usr/local/Cellar/libvorbis/1.3.5/lib/"
Binary name "libvorbis.0.dylib"
Binary path "/usr/local/Cellar/libvorbis/1.3.5/lib/libvorbis.0.dylib"
Version ""
Install name "/usr/local/opt/libvorbis/lib/libvorbis.0.dylib"
Deployed install name "@executable_path/../Frameworks/libvorbis.0.dylib"
Source file Path "/usr/local/Cellar/libvorbis/1.3.5/lib/libvorbis.0.dylib"
Framework Destination Directory (relative to bundle) "Contents/Frameworks/"
Binary Destination Directory (relative to bundle) "Contents/Frameworks/"


This is apparently not yet solved in newer Qt versions.

I tried with a workaround:
https://github.com/musescore/MuseScore/pull/2972
it is not the most elegant way to solve the problem.

Unfortunately, I couldn't test this change on my computer, so I am not 100% sure that it works.

@ABL: I compiled from the proposed patch, and still crashed on startup. Log attached.

@Isaac this crashlog is different. Try to run MuseScore with -F. I tested the patch and it seems to work here. At least otool output is ok. I will merge it so we can try a nightly.

Fixed in branch master, commit e5dd938607

fix #152151 [Mac] Nightlies crash on start

Fixed in branch master, commit 6fdce0a393

Merge pull request #2972 from AntonioBL/macprova

fix #152151 [Mac] Nightlies crash on start

I'll be able to test in 90 minutes (on phone right now).

It starts!

I can't get it to start normally (see attached log).

I then opened Terminal, dragged mscore (within MacOS) onto it, typed -F and pressed enter.

It complains this:

dyld: Library not loaded: /usr/local/Cellar/libvorbis/1.3.5/lib/libvorbis.0.dylib
Referenced from: /Applications/MuseScore/3.0/MuseScoreNightly.app/Contents/Frameworks/libvorbisenc.2.dylib
Reason: image not found
Trace/BPT trap: 5

Using 6fdce0a - Mac 10.11.6.

The old patch was taking into account only dependencies directly called by the main application. In this new PR (locally tested) all dylib bundled inside MuseScore are now patched during deployment:
https://github.com/musescore/MuseScore/pull/2973

Fixed in branch master, commit 2f98dae2ee

fix #152151 fix Mac deployment for all libraries

FWIW, in the first place, I don't think there is an issue with direct dependencies, but only with dependencies of dependencies.
The very first trace mentions libvorbisfile

Library not loaded: /usr/local/Cellar/libvorbis/1.3.5/lib/libvorbis.0.dylib
Referenced from: /Applications/MuseScoreNightly.app/Contents/Frameworks/libvorbisfile.3.dylib
Reason: image not found

Automatically closed -- issue fixed for 2 weeks with no activity.

Reports coming in of the issue with the libvorbis library still causing a crash:

https://musescore.org/en/node/174571
https://musescore.org/en/node/166991#comment-657911

Worrisomely, both people are talking about 2.1.

Nothing to worry about. Is it working for you?

I'm not having any problems.

Fixed in branch master, commit ad14e40f04

Fix #152151: change paths in bottled dylib

Fixed in branch master, commit 0351aec381

Merge pull request #3006 from lasconic/fix-travis-macos

Fix #152151: change paths in bottled dylib

Please apply it to the 2.1 build as well.

Fixed in branch 2.1, commit 5a0653b0ea

Fix #152151: change paths in bottled dylib

It should be fixed again. Tests very welcome.

Tested MuseScoreNightly-2017-02-19-0847-2.1-e6a9100.dmg and one of the 3.0 versions from yesterday.
They both work now.
Thank you!

Automatically closed -- issue fixed for 2 weeks with no activity.