Segmentation fault on Manjaro Linux after installing MuseSounds

[Schweini07]

Issue type

Crash or freeze

Bug description

I've freshly downloaded MuseScore from pacman, and after working on a piece for a while I wanted to get MuseSounds for a piano to properly play staccato notes. After the installation I wasn't able to start MuseScore anymore though, and after running it through the terminal it seems like a segfault is the culprit here.

Steps to reproduce

1. Download MuseScore from the official repositories via pacman
2. Install MuseSound Manager from AUR
3. Install Keys sound suite
4. Try to start Musescore

Screenshots/Screen recordings

No response

MuseScore Version

MuseScore4 4.2.1

Regression

I don't know

Operating system

Manjaro Linux

Additional context

I ran the core file with gdb, to look at the backtrace, but I don't think I can provide much more info. If there is still anything I can provide, please do tell. bt:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f37bfb09af1 in ms_InstrumentList_get_next () from /home/laurenz/.local/share/MuseSampler/lib/libMuseSamplerCoreLib.so
[Current thread is 1 (Thread 0x7f37f1dfb6c0 (LWP 16757))]
(gdb) bt
#0  0x00007f37bfb09af1 in ms_InstrumentList_get_next () at /home/laurenz/.local/share/MuseSampler/lib/libMuseSamplerCoreLib.so
#1  0x000055c5d9fbd1f9 in ??? ()
#2  0x000055c5d952963d in ??? ()
#3  0x000055c5d9575633 in ??? ()
#4  0x000055c5d958bd5e in ??? ()
#5  0x000055c5d8e86da4 in ??? ()
#6  0x000055c5d8e941ca in ??? ()
#7  0x000055c5d8b3d6a6 in ??? ()
#8  0x00007f38236dcb63 in std::execute_native_thread_routine (__p=0x55c5de106690) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/thread.cc:104
#9  0x00007f3824f3d1cf in ??? () at /usr/lib/libc.so.6
#10 0x00007f3824fbe6ec in ??? () at /usr/lib/libc.so.6

bt full:

#0  0x00007f37bfb09af1 in ms_InstrumentList_get_next () at /home/laurenz/.local/share/MuseSampler/lib/libMuseSamplerCoreLib.so
#1  0x000055c5d9fbd1f9 in ??? ()
#2  0x000055c5d952963d in ??? ()
#3  0x000055c5d9575633 in ??? ()
#4  0x000055c5d958bd5e in ??? ()
#5  0x000055c5d8e86da4 in ??? ()
#6  0x000055c5d8e941ca in ??? ()
#7  0x000055c5d8b3d6a6 in ??? ()
#8  0x00007f38236dcb63 in std::execute_native_thread_routine (__p=0x55c5de106690) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/thread.cc:104
        __t = std::unique_ptr<std::thread::_State> = {get() = <optimized out>}
#9  0x00007f3824f3d1cf in ??? () at /usr/lib/libc.so.6
#10 0x00007f3824fbe6ec in ??? () at /usr/lib/libc.so.6

info threads:

  Id   Target Id                         Frame 
* 1    Thread 0x7f37f1dfb6c0 (LWP 16757) 0x00007f37bfb09af1 in ms_InstrumentList_get_next () from /home/laurenz/.local/share/MuseSampler/lib/libMuseSamplerCoreLib.so
  2    Thread 0x7f381f1356c0 (LWP 16739) 0x00007f3824fb09ed in poll () from /usr/lib/libc.so.6
  3    Thread 0x7f381f759940 (LWP 16738) 0x00007f3824f4d0ca in ?? () from /usr/lib/libc.so.6
  4    Thread 0x7f381cc9f6c0 (LWP 16741) 0x00007f3824fbc48d in syscall () from /usr/lib/libc.so.6
  5    Thread 0x7f38027fc6c0 (LWP 16748) 0x00007f3824f398d9 in ?? () from /usr/lib/libc.so.6
  6    Thread 0x7f381e9346c0 (LWP 16740) 0x00007f3824fb09ed in poll () from /usr/lib/libc.so.6
  7    Thread 0x7f3803fff6c0 (LWP 16745) 0x00007f3824f398d9 in ?? () from /usr/lib/libc.so.6
  8    Thread 0x7f38037fe6c0 (LWP 16746) 0x00007f3824f398d9 in ?? () from /usr/lib/libc.so.6
  9    Thread 0x7f38177fe6c0 (LWP 16743) 0x00007f3824fb09ed in poll () from /usr/lib/libc.so.6
  10   Thread 0x7f37f3dff6c0 (LWP 16752) 0x00007f3824fbeaf2 in epoll_wait () from /usr/lib/libc.so.6
  11   Thread 0x7f37bf4d86c0 (LWP 16760) 0x00007f3824fb09ed in poll () from /usr/lib/libc.so.6
  12   Thread 0x7f38017fa6c0 (LWP 16750) 0x00007f3824f398d9 in ?? () from /usr/lib/libc.so.6
  13   Thread 0x7f37f25fc6c0 (LWP 16756) 0x00007f3824fb09ed in poll () from /usr/lib/libc.so.6
  14   Thread 0x7f37f35fe6c0 (LWP 16753) 0x00007f3824fbeaf2 in epoll_wait () from /usr/lib/libc.so.6
  15   Thread 0x7f3802ffd6c0 (LWP 16747) 0x00007f3824f398d9 in ?? () from /usr/lib/libc.so.6
  16   Thread 0x7f3801ffb6c0 (LWP 16749) 0x00007f3824f398d9 in ?? () from /usr/lib/libc.so.6
  17   Thread 0x7f3817fff6c0 (LWP 16742) 0x00007f3824fb09ed in poll () from /usr/lib/libc.so.6
  18   Thread 0x7f3816ffd6c0 (LWP 16744) 0x00007f3824fb09ed in poll () from /usr/lib/libc.so.6
  19   Thread 0x7f3800cae6c0 (LWP 16751) 0x00007f3824f398d9 in ?? () from /usr/lib/libc.so.6
  20   Thread 0x7f37f2dfd6c0 (LWP 16754) 0x00007f3824fbeaf2 in epoll_wait () from /usr/lib/libc.so.6
  21   Thread 0x7f37f15fa6c0 (LWP 16758) 0x00007f3824f398d9 in ?? () from /usr/lib/libc.so.6
  22   Thread 0x7f37f0df96c0 (LWP 16759) 0x00007f3824f398d9 in ?? () from /usr/lib/libc.so.6

[MarcSabatella]

Those third party builds often have errors that lead to problems like this. What happens if you instead use the official supported AppImage instead of that other build from the repository?

[Schweini07]

The Appimage provided by the MuseScore download site, seems to only be MuseScore itself. Or do I have to look somewhere else?

Anyways, it might also be unrelated to that, as I tried deleting the manager and its installed instruments right now, and the crash still occurs. So maybe there is a different reason for the segfault?

[Schweini07]

The program also still crashes after a complete reinstall with pacman, which is unfortunate :smiling_face_with_tear:

[MarcSabatella]

Normally you should be installing the AppImage of MuseScore Studio, plus the DEB or RPM file for Muse Sounds Manager.
I gather there are other unofficial packages of Muse Sounds Manager for distributions that are unable to use DEB or RPM files, which you can use at your own risk but I'm not aware of any reported problems with them. MuseScore Studio itself is another matter, though. Definitely you should not be attempting to install thrid-party builds of MuseScore Studio, as many are known not to work. Only the AppImage is supported.

So if you see a crash using the AppImage, definitely followup and post more details. But if it only occurs with a third party build, that's a problem you'd need to report to the folks who produced it.

[Schweini07]

I see, actually with the appimage I am not experiencing any crashes anymore, so it might very well be the fault of the package. Although the package is from the official repositories, so I would have thought that works out of the box. I might try to contact the maintainer of the package.

[Schweini07]

I looked a bit through arch linux related issues right now, and it seems that the problem might very well be related to this one: https://github.com/musescore/MuseScore/issues/22926 So I assume the fault lays with the official arch package.

[kisaragi-hiu]

The segfault is coming from distro-built executable loading the upstream-built libMuseSamplerCoreLib.so, probably because some things just don't line up properly when the main app and the library are built separately like this.

Is there a reason why the libMuseSamplerCoreLib.so that appears to be installed by MuseHub / Muse Sounds Manager cannot be built as a part of MuseScore itself? While the size of Muse Sounds justifies a separate distribution method, this library is just 7.9 MiB.

[cbjeukendrup]

The reason is licensing. MuseScore is open source (GPL3), while libMuseSamplerCoreLib.so is closed source (I don't know which license). And that makes it impossible to package that library with MuseScore.

[kisaragi-hiu]

Then, well… This gets into opinions territory, but it'd be better if libMuseSamplerCoreLib.so is open sourced, if Muse can make that decision.

Whether something is released as open source is 100% the discretion of its rightsholders (Muse in this case AFAICT), and I do not contest this point.

But this library being a closed source magical black box means:

• Frustration as Muse Sounds just break on Linux in an undocumented way
• Linux users being forced to use the portable AppImage, which ~~has no inbuilt way to add a shortcut to the system launcher~~ does not integrate with the system's update mechanism (updated together with everything else on the system in the system package manager, and a user doesn't have to decide for themself where to put executable programs), is marketed as "Portable", and shouldn't be the only option in the first place (Edit: striked the inaccurate statement and clarified what I meant by "system update mechanism").
• Muse Sounds Manager having to inexplicably dump a random shared library in ~/.local/share/MuseSampler
• This issue, which is related to the point above (loading prebuilt shared libraries is complicated)

All for no apparent benefit for the application. Unless this library itself licenses proprietary technology (understandable), but the "MuseSampler" branding makes me guess that's not the case.

This is still 100% up to Muse. I just think this component being open source like the rest of MuseScore Studio would make a better product.

[MarcSabatella]

@kisaragi-hiu Just a note - while it's true that the AppImage doesn't integrate with the system update, it's not true it doesn't update with the launcher. Just run it with the "install" option and it creates its own desktop file, icon, file associations, etc. It will be as fully integrated as any other app as far as your launcher goes. And running it with the "update" option is a very easy way to update. The AppImage is also well tested and guaranteed to have been built correctly, whereas third-party builds very often have all sorts of hard-to-diagnsoe errors. You shouldn't think of it as something you are "forced" to run - it really is a better experience all around.

But that of course is a totally separate discussion. if you need help learning how to use the "install" or "update" options for the AppImage, please ask on the Support forum at musescore.org.

[kisaragi-hiu]

You shouldn't think of it as something you are "forced" to run

That Muse Sounds currently only works with the AppImage (at least in some cases, maybe the prebuilt library works on Ubuntu?) due to this segfault is a fact, not a matter of my perception. My understanding (or lack thereof) of the usage of AppImages is besides the point, and this issue is about making the product better.

---

As I see it, there are a few ways to tackle this segfault:

• Disable the Muse Sounds option for the default build and only enable it for the AppImage build, encouraging distros to keep it off. Works around this footgun (installing from system repositories like other programs, installing Muse Sounds as an addon, then triggering this issue). Will cause people to formally be annoyed as it would formally highlight how Muse Sounds support (libMuseSamplerCoreLib.so) is a proprietary addon.
• Keep the UI as-is but explain, in the downloads page, how Muse Sounds only works with the AppImage build, perhaps for now, keeping the footgun in the UI but at least steering people away from it.
• Keep everything as-is but guard against this segfault, so the end result is Muse Sounds continuing to be greyed out (possibly with an explanation that the sampler failed to load) instead of #22926.
• Open source libMuseSamplerCoreLib.so so that the segfault could be investigated then fixed for all builds, instead of relying on the fragile environment inside of an AppImage. This also avoids having to have Muse Sounds Manager distribute libMuseSamplerCoreLib.so with zero indication that it's doing that, instead having code be distributed with code. May not be possible - an explanation would help a lot in that case.
• Or Muse investigates this segfault internally - apparently coming from the function ms_InstrumentList_get_next as per OP's backtrace - and fix it so that it works on all platforms, instead of refusing to work outside of the AppImage platform.

[konradglas]

@Schweini07 Could you run (gdb) info locals when gdb breaks because of the segfault? Also please provide the MuseScore logs. May also be helpful to know if any instruments were actually loaded (successfully)

[Schweini07]

I don't have the core dump anymore, unfortunately. But interestingly enough MuseScore works again now, if I open it. Maybe the package has been updated to fix the issue :slightly_smiling_face:?

[bkunda]

Thanks for verifying this @Schweini07. Let's close this now then as it seems the problem no longer occurs.