MuseScore
MuseScore copied to clipboard
musescore
[MU4 Issue] Can't get core function pointer when launching app (crash on launch)
Describe the bug Musescore loading screen loads up and then throws error "Can't get core function pointer". It seems like some kind of VST error, but there is no way to disable VST's it seems. I have already deleted all of the incompatible AU plugins that Logic discovered.
To Reproduce Steps to reproduce the behavior:
- Install MU4
- Launch the app
- Get error
Expected behavior A clear and concise description of what you expected to happen.
Screenshots If applicable, add screenshots to help explain your problem.
Platform information
- OS: macOS 12.6.1 (21G217)
- MacBook Pro (14-inch, 2021)
- Apple M1 Pro
Additional context I have some VST's and Audio Units installed. Something that's common in various Mac apps is that you can launch the app in safe mode by holding Shift while launching. If this issue is caused by a VST plugin, adding this feature would be really helpful.
By googling this error message, I gather that it might be caused by the iZotope Ozone VST plugin.
This should not cause MuseScore to crash though. It's a somewhat blind guess, but could you please try if this is fixed in the version at https://github.com/musescore/MuseScore/suites/8970569180/artifacts/412521024 ?
Funnily enough, I have the Izotope Ozone 9 VST and I've never experienced this. Very strange. However, definitely worth trying to disable it momentarily (by removing the plugin temporarily and booting MuseScore).
It may be another VST too. We'd really appreciate it if you test a little bit to determine if it is a VST issue because that would help us a lot in solving it!
@Tantacrul @LoveJessyChen I can't reproduce this on my macOS. All the Ozone 10/RX 10 plugins work fine and don't cause any crashes/errors on my computer. I need more info on which plugin is causing the problem. @LoveJessyChen could you please send me the app logs when you are able to reproduce the problem? On my macOS, they are here: /Users/work/Library/Application Support/MuseScore/MuseScore4/logs
Thank you!
Same here. Just installed MU4 and I cannot open it 'cos got the same message "Can't get core function pointer". I dont have ozone installed, just iZotope RX.
OS: macOS 12.6 (21G115) MacBook Pro (16-inch, 2021) Apple M1 Pro
Any idea how can I bypass this?
@jacopogrecodalceo could you please send me the app logs? On my macOS, they are here: /Users/work/Library/Application Support/MuseScore/MuseScore4/logs
Thank you!
Yap, i'm sorry wanted to send you, but forgot.
I may have additional information on this bug, or it may be a different one. This is on the same platform OP uses.
I got MuseScore to start successfully after seeing this error by restarting the application 18 times. This was likely once per incompatible VST plugin installed on my machine.
After each "Can't get core function pointer" error, ~/Library/Application Support/MuseScore/MuseScore4/vst/ contained 1–3 new .json files. Some of them seemed to disable incompatible plugins, e.g.:
{
"enabled": false,
"meta": "",
"path": "/Library/Audio/Plug-Ins/VST3/[VST Name].vst3",
"type": ""
}
I thus wonder if this bug isn't tightly connected to an incompatible Ozone plugin, but rather an error in how disabling incompatible VSTs is handled. Seems like MuseScore crashes after detecting such a plugin, but then skips it correctly on the next startup.
Here's one of the logs from the first 17 starts when MuseScore crashed: (last line seems relevant)
2022-12-17T07:52:31.828 | INFO | main_thread | GlobalModule | onPreInit: log path: /Users/[USER]/Library/Application Support/MuseScore/MuseScore4/logs/MuseScore_221217_075231.log
2022-12-17T07:52:31.829 | INFO | main_thread | GlobalModule | onPreInit: === Started MuseScore 4.0.0, build number 223472200 ===
2022-12-17T07:52:31.933 | INFO | main_thread | DiagnosticsModule | onInit: success start crash handler
2022-12-17T07:52:31.947 | WARN | main_thread | Qt | QIODevice::read (QFile, "/Users/[USER]/Library/Application Support/MuseScore/MuseScore4/shortcuts.xml"): device not open
2022-12-17T07:52:31.947 | WARN | main_thread | Qt | QIODevice::read (QFile, "/Users/[USER]/Library/Application Support/MuseScore/MuseScore4/midi_mappings.xml"): device not open
2022-12-17T07:52:32.038 | ERROR | main_thread | MuseSamplerLibHandler | MuseSamplerLibHandler: Unable to open MuseSampler library, path: /usr/local/lib/libMuseSamplerCoreLib.dylib
2022-12-17T07:52:32.038 | ERROR | main_thread | MuseSamplerResolver | checkLibrary: Incompatible MuseSampler library; ignoring
Can anyone reproduce this behavior? @jacopogrecodalceo @LoveJessyChen
EDIT: Removing one of the {"enabled": false,} json files causes the crash again, and MuseScore recreates the file. I'm now trying to build and test against RomanPudashkin:vst_crashes but so far finding it hard to get the correct QT version set up for development atm.
EDIT 2: As I explore, here's the stack trace of the actual crash. Crash seems to be in VST3::Hosting::Module::create:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 ??? 0x7ff89b6f29a8 ???
1 libsystem_kernel.dylib 0x7ff80c43330e __pthread_kill + 10
2 libsystem_pthread.dylib 0x7ff80c46af7b pthread_kill + 263
3 libsystem_c.dylib 0x7ff80c3b4ca5 abort + 123
4 libc++abi.dylib 0x7ff80c425082 abort_message + 241
5 libc++abi.dylib 0x7ff80c416163 demangling_terminate_handler() + 48
6 libc++abi.dylib 0x7ff80c4244a5 std::__terminate(void (*)()) + 8
7 libc++abi.dylib 0x7ff80c424440 std::terminate() + 32
8 mscore 0x1040ba8cf 0x102a01000 + 23828687
9 mscore 0x1040b8379 VST3::Hosting::Module::create(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) + 281
10 mscore 0x103ade8f2 mu::vst::VstModulesRepository::createModule(mu::io::path_t const&) + 82
11 mscore 0x103adf864 mu::vst::VstModulesRepository::addModule(mu::io::path_t const&) + 100
12 mscore 0x103adf04d mu::vst::VstModulesRepository::refresh() + 525
13 mscore 0x103addb51 mu::vst::VstModulesRepository::init() + 273
14 mscore 0x10327926d mu::appshell::AppShell::run(int, char**) + 2349
15 mscore 0x102a0d0b2 main + 1698
16 dyld 0x205ee9310 start + 2432
I may have additional information on this bug, or it may be a different one. This is on the same platform OP uses.
I got MuseScore to start successfully after seeing this error by restarting the application 18 times. This was likely once per incompatible VST plugin installed on my machine. After each "Can't get core function pointer" error,
~/Library/Application Support/MuseScore/MuseScore4/vst/contained 1–3 new.jsonfiles. Some of them seemed to disable incompatible plugins, e.g.:{ "enabled": false, "meta": "", "path": "/Library/Audio/Plug-Ins/VST3/[VST Name].vst3", "type": "" }I thus wonder if this bug isn't tightly connected to an incompatible Ozone plugin, but rather an error in how disabling incompatible VSTs is handled. Seems like MuseScore crashes after detecting such a plugin, but then skips it correctly on the next startup.
Here's one of the logs from the first 17 starts when MuseScore crashed: (last line seems relevant)
2022-12-17T07:52:31.828 | INFO | main_thread | GlobalModule | onPreInit: log path: /Users/[USER]/Library/Application Support/MuseScore/MuseScore4/logs/MuseScore_221217_075231.log 2022-12-17T07:52:31.829 | INFO | main_thread | GlobalModule | onPreInit: === Started MuseScore 4.0.0, build number 223472200 === 2022-12-17T07:52:31.933 | INFO | main_thread | DiagnosticsModule | onInit: success start crash handler 2022-12-17T07:52:31.947 | WARN | main_thread | Qt | QIODevice::read (QFile, "/Users/[USER]/Library/Application Support/MuseScore/MuseScore4/shortcuts.xml"): device not open 2022-12-17T07:52:31.947 | WARN | main_thread | Qt | QIODevice::read (QFile, "/Users/[USER]/Library/Application Support/MuseScore/MuseScore4/midi_mappings.xml"): device not open 2022-12-17T07:52:32.038 | ERROR | main_thread | MuseSamplerLibHandler | MuseSamplerLibHandler: Unable to open MuseSampler library, path: /usr/local/lib/libMuseSamplerCoreLib.dylib 2022-12-17T07:52:32.038 | ERROR | main_thread | MuseSamplerResolver | checkLibrary: Incompatible MuseSampler library; ignoringCan anyone reproduce this behavior? @jacopogrecodalceo @LoveJessyChen
EDIT: Removing one of the
{"enabled": false,}json files causes the crash again, and MuseScore recreates the file. I'm now trying to build and test against RomanPudashkin:vst_crashes but so far finding it hard to get the correct QT version set up for development atm.EDIT 2: As I explore, here's the stack trace of the actual crash. Crash seems to be in
VST3::Hosting::Module::create:Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 ??? 0x7ff89b6f29a8 ??? 1 libsystem_kernel.dylib 0x7ff80c43330e __pthread_kill + 10 2 libsystem_pthread.dylib 0x7ff80c46af7b pthread_kill + 263 3 libsystem_c.dylib 0x7ff80c3b4ca5 abort + 123 4 libc++abi.dylib 0x7ff80c425082 abort_message + 241 5 libc++abi.dylib 0x7ff80c416163 demangling_terminate_handler() + 48 6 libc++abi.dylib 0x7ff80c4244a5 std::__terminate(void (*)()) + 8 7 libc++abi.dylib 0x7ff80c424440 std::terminate() + 32 8 mscore 0x1040ba8cf 0x102a01000 + 23828687 9 mscore 0x1040b8379 VST3::Hosting::Module::create(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >&) + 281 10 mscore 0x103ade8f2 mu::vst::VstModulesRepository::createModule(mu::io::path_t const&) + 82 11 mscore 0x103adf864 mu::vst::VstModulesRepository::addModule(mu::io::path_t const&) + 100 12 mscore 0x103adf04d mu::vst::VstModulesRepository::refresh() + 525 13 mscore 0x103addb51 mu::vst::VstModulesRepository::init() + 273 14 mscore 0x10327926d mu::appshell::AppShell::run(int, char**) + 2349 15 mscore 0x102a0d0b2 main + 1698 16 dyld 0x205ee9310 start + 2432
Ah! You're right. Good sight. I can open MU4 insisting on opening it!
I think it's because the VST plugin is Apple Silicone only (arm64) while MuseScore is Intel only. Thus when MuseScore tries to load arm64 plugins it failed because an Intel app can only run Intel subprocesses, even after it's translated to arm64. Below is the output of mscore to prove this. Note that the VST actually changes every time so it seems like if you relaunch it sufficient times it would disable all "non-compatible" VST plugins and launch.
2022-12-26 17:40:39.922 mscore[94392:50363315] Error loading /Library/Audio/Plug-Ins/VST3/RX 10 De-click.vst3/Contents/Resources/iZRX10De-click.bundle/Contents/MacOS/iZRX10De-click: dlopen(/Library/Audio/Plug-Ins/VST3/RX 10 De-click.vst3/Contents/Resources/iZRX10De-click.bundle/Contents/MacOS/iZRX10De-click, 0x0106): tried: '/Library/Audio/Plug-Ins/VST3/RX 10 De-click.vst3/Contents/Resources/iZRX10De-click.bundle/Contents/MacOS/iZRX10De-click' (fat file, but missing compatible architecture (have 'arm64', need 'x86_64'))
libc++abi: terminating
fish: Job 1, '/Applications/MuseScore\ 4.app/…' terminated by signal SIGABRT (Abort)
@sclsj Thanks! That makes a lot of sense to me. I downloaded the free trial of some iZotope plugins and I still couldn't reproduce the problem, but after modifying the plugin files to delete the x86_64 parts from the binary files to make them effectively arm64 only. The situation is as follows:
The vst3 file at /Library/Audio/Plug-Ins/VST3/RX 10 De-click.vst3 is a "bundle" on macOS; basically, just a folder with some special structure.
Inside the bundle, you have the main plugin library file at /Library/Audio/Plug-Ins/VST3/RX 10 De-click.vst3/Contents/MacOS/PluginHooksVST3. This file is loaded by MuseScore, via the VST SDK, with proper error handling. So if I delete the x86_64 version from this binary file, MuseScore does not crash, but gracefully handles the error.
But in the case of the iZotope plugins, there is another library: /Library/Audio/Plug-Ins/VST3/RX 10 De-click.vst3/Contents/Resources/iZRX10De-click.bundle/Contents/MacOS/iZRX10De-click. Apparently, the main plugin library tries to load this library, but has no proper error handling or does something different wrong, which causes MuseScore to crash. If I delete the x86_64 version from this binary file, I get the "Can't get core function pointer" error and MuseScore crashes.
Since the crash really seems to happen inside the plugin library, it looks like we can't do anything about this. However, for me this only happens in a self-modified version of the iZotope plugins, and not after simply installing out of the box. So I suggest you re-download the plugins from the iZotope website and reinstall them, to make sure that the plugins are intact.
(By the way, for modifying the binary files, I use the lipo command line tool on macOS. Also, modifying these plugins may actually be prohibited by their license.)
One more note: MuseScore's "algorithm" for registering plugins is like this:
For every plugin path:
- Register the plugin as disabled
- Try to load the plugin
- If it worked: register it as enabled.
So if MuseScore crashes while loading a plugin, that plugin is still registered as disabled, so MuseScore won't try to reload it the next time. So, @ludwigschubert and @jacopogrecodalceo you were right that if you try often enough, MuseScore will eventually have registered all problematic plugins as "disabled" and then start correctly.
@sclsj Thanks! That makes a lot of sense to me. I downloaded the free trial of some iZotope plugins and I still couldn't reproduce the problem, but after modifying the plugin files to delete the x86_64 parts from the binary files to make them effectively arm64 only. The situation is as follows:
The vst3 file at
/Library/Audio/Plug-Ins/VST3/RX 10 De-click.vst3is a "bundle" on macOS; basically, just a folder with some special structure.Inside the bundle, you have the main plugin library file at
/Library/Audio/Plug-Ins/VST3/RX 10 De-click.vst3/Contents/MacOS/PluginHooksVST3. This file is loaded by MuseScore, via the VST SDK, with proper error handling. So if I delete the x86_64 version from this binary file, MuseScore does not crash, but gracefully handles the error.But in the case of the iZotope plugins, there is another library:
/Library/Audio/Plug-Ins/VST3/RX 10 De-click.vst3/Contents/Resources/iZRX10De-click.bundle/Contents/MacOS/iZRX10De-click. Apparently, the main plugin library tries to load this library, but has no proper error handling or does something different wrong, which causes MuseScore to crash. If I delete the x86_64 version from this binary file, I get the "Can't get core function pointer" error and MuseScore crashes.Since the crash really seems to happen inside the plugin library, it looks like we can't do anything about this. However, for me this only happens in a self-modified version of the iZotope plugins, and not after simply installing out of the box. So I suggest you re-download the plugins from the iZotope website and reinstall them, to make sure that the plugins are intact.
(By the way, for modifying the binary files, I use the
lipocommand line tool on macOS. Also, modifying these plugins may actually be prohibited by their license.)
I'm not sure why you got a universal binary while I have arm64 only. Perhaps try RX 10 Audio Editor Advanced? Latest version. That's where I got my set of plugins.
It might also be the case that I manually thinned the plugins some time ago and forgot about it. For code-only ones the space saving is up to 50% and removing the x86 component (very conveniently) does not damage the code signature or notarization.
The script I used (not very elegant, run using fish):
for i in **
lipo -extract arm64 $i -o $i.1
mv $i.1 $i
end
Edit: I found out that's because I installed a cracked version of Izotope. It overwrote the inner binary with an arm64-only version and left the outer binary intact (universal), causing this problem.
@sclsj Strange, that links to the exact same installer as I had downloaded... Also, with the crash you are having, apparently the main plugin file called PluginHooksVST3 does have a x86_64 component, only the "inner" binary file called iZRX10De-click is missing it. Otherwise, MuseScore would have handled the error without crashing. It would be very strange if the installer delivered such an inconsistent version of the plugin, where some binaries are both x86_64 and arm64 and others are missing the x86_64 part. So it is indeed very probably that you modified the plugins yourself. Not sure about the other users experiencing this crash though...
Same problem. Musescore was working kind of ok until I installed Izotope RX. Uptdated Musescore to 4.01. Same problem.
hi, random user here: Just going to mention this is still happening, and I have so many Izotope and arm64 plugins on my computer that it'll take a lot more time to get through all of them. If there's some way we can just stop Musescore from automatically searching for plugins on startup (if not to get it to not crash for each one) that would be incredibly helpful and would make it accessible again for me. (if I'm supposed to add this somewhere else let me know!)
hi, random user here: Just going to mention this is still happening, and I have so many Izotope and arm64 plugins on my computer that it'll take a lot more time to get through all of them. If there's some way we can just stop Musescore from automatically searching for plugins on startup (if not to get it to not crash for each one) that would be incredibly helpful and would make it accessible again for me. (if I'm supposed to add this somewhere else let me know!)
The problem is that you have mixed fat and thin (arm64 only) binaries in the plugin folder. You can either try using my script to manually remove the x86 part and make the plugin pure arm64 or manually register all plugins as disabled (not sure how you would do that, pseudocode below):
for i in (incompatible vst list)
create file ~/Library/Application\ Support/MuseScore/MuseScore4/vst/<vst name>.json
write to file:
{
"enabled": false,
"meta": "",
"path": "<vst path>",
"type": ""
}
And just to be clear, are everyone here (experiencing this problem) using the official, unmodified version of Izotope plugins? I felt like the reason why we are having problems is that we are using a cracked version. I think my release is from MORiA but apparently during the modification the x86 version of the "inner" binary got removed but not the "outer" binary, probably because the authentication / licensing is done by the "inner" binary.
Edit: That's incorrect. The version I downloaded is indicated as "m1 only", and the only files included in the patch are the inner binaries, so the outer binary remains universal but the inner one is arm64 only.
Edit 2: Still incorrect. I remember downloading a version where there is a m1 pkg + intel pkg. I think that's where the problem came from.
.. crap. yeah I think that's it. I think only the m1 pkg was installed but if there is a problem that's definitely somewhere it could be; do you know how I could try and get past that? I feel like if that is the problem it's definitely not going to be as high of a priority for Musescore staff, but it is likely the case.
.. crap. yeah I think that's it. I think only the m1 pkg was installed but if there is a problem that's definitely somewhere it could be; do you know how I could try and get past that? I feel like if that is the problem it's definitely not going to be as high of a priority for Musescore staff, but it is likely the case.
Try thinning the outer binary with lipo. For an example, see the script I posted.
I am working on rewriting how MuseScore scans VST plugins. Starting from version 4.1, the application will run a separate process for each plugin the first time it is scanned. This will avoid all the crashes described here (even if these auxiliary processes crash, they will not affect the main application). In fact, this approach is used in all DAWs (e.g., Reaper)
Also see: https://github.com/musescore/MuseScore/issues/15967
Just had this today. Never tried Musescore4 before. The simple solution was to remove all my VST3s from /Library/Audio/Plug-Ins/VST3 into a backup folder...I use Logic normally so never used these before...i'll add them back in as I need them, and probably find the culprit then...ironically, often had the same issue with Finale and Sibelius over the years, lol.
as the author of a DAW (ossia score) whose users are encountering the same problem with the same plug-in, @DmitryArefiev could you share what was the fix for this exactly? the #16990 PR is kinda large... I already use a separate plug-in scanner for quite some time to allow the software to launch even with faulty plug-ins, but my users are still annoyed by the numerous "Can't get core function pointer" crash dialogs that each scanning process has when encountering those.
@jcelerier The main thing that PR did, was moving the plugin scanning into a separate process, so nothing new for you 🙂. And the rest is probably not very interesting.
However, what we also do (and did already before that PR), is remembering which plugins caused a crash (we store that data in a simple JSON file), and next time we will ignore those plugins. Therefore the user will encounter the "core function pointer" dialog only once per plugin, until the user chooses to rescan all plugins.
So we don't have a "real" fix to prevent those dialogs, but I think that would be simply impossible because it's caused by an error in the plugin itself.
Hope that helps!