Description of problem: After encountering bug 2257257, I've tried to start mscore again - now it crashed right when starting ... Version-Release number of selected component: musescore-4.2.0-5.fc39 Additional info: reporter: libreport-2.17.11 type: CCpp reason: mscore killed by SIGABRT journald_cursor: s=02fd56fde1da4b348839ff6293944165;i=f021f17;b=a824ff45863d4e0fbaa8e78d4aa6ed14;m=7ae9bfe587;t=60e6e2bab77b0;x=39eb396c9a210e executable: /usr/bin/mscore cmdline: mscore 2000-04-28.mid cgroup: 0::/user.slice/user-1000.slice/user/app.slice/app-org.kde.konsole-f8094e0fcb0a4646912d84a08a6b630a.scope rootdir: / uid: 1000 kernel: 6.6.8-200.fc39.x86_64 package: musescore-4.2.0-5.fc39 runlevel: N 5 backtrace_rating: 4 crash_function: std::__glibcxx_assert_fail comment: After encountering bug 2257257, I've tried to start mscore again - now it crashed right when starting ... Truncated backtrace: Thread no. 1 (19 frames) #4 std::__glibcxx_assert_fail at ../../../../../libstdc++-v3/src/c++11/assert_fail.cc:41 #5 std::array<mu::engraving::PropertyValue, 1433ul>::operator[] at /usr/include/c++/13/array:208 #7 mu::engraving::MStyle::value at /usr/src/debug/musescore-4.2.0-5.fc39.x86_64/src/engraving/style/style.cpp:50 #8 mu::engraving::MStyle::styleV at /usr/src/debug/musescore-4.2.0-5.fc39.x86_64/src/engraving/style/style.h:52 #9 mu::engraving::EngravingObject::styleValue at /usr/src/debug/musescore-4.2.0-5.fc39.x86_64/src/engraving/dom/engravingobject.cpp:768 #10 mu::engraving::EngravingObject::initElementStyle at /usr/src/debug/musescore-4.2.0-5.fc39.x86_64/src/engraving/dom/engravingobject.cpp:324 #11 mu::engraving::Pedal::Pedal at /usr/src/debug/musescore-4.2.0-5.fc39.x86_64/src/engraving/dom/pedal.cpp:105 #12 std::_Construct<mu::engraving::Pedal, mu::engraving::compat::DummyElement*> at /usr/include/c++/13/bits/stl_construct.h:119 #13 std::allocator_traits<std::allocator<void> >::construct<mu::engraving::Pedal, mu::engraving::compat::DummyElement*> at /usr/include/c++/13/bits/alloc_traits.h:661 #14 std::_Sp_counted_ptr_inplace<mu::engraving::Pedal, std::allocator<void>, (__gnu_cxx::_Lock_policy)2>::_Sp_counted_ptr_inplace<mu::engraving::compat::DummyElement*> at /usr/include/c++/13/bits/shared_ptr_base.h:604 #15 std::__shared_count<(__gnu_cxx::_Lock_policy)2>::__shared_count<mu::engraving::Pedal, std::allocator<void>, mu::engraving::compat::DummyElement*> at /usr/include/c++/13/bits/shared_ptr_base.h:971 #16 std::__shared_ptr<mu::engraving::Pedal, (__gnu_cxx::_Lock_policy)2>::__shared_ptr<std::allocator<void>, mu::engraving::compat::DummyElement*> at /usr/include/c++/13/bits/shared_ptr_base.h:1712 #17 std::shared_ptr<mu::engraving::Pedal>::shared_ptr<std::allocator<void>, mu::engraving::compat::DummyElement*> at /usr/include/c++/13/bits/shared_ptr.h:464 #18 std::make_shared<mu::engraving::Pedal, mu::engraving::compat::DummyElement*> at /usr/include/c++/13/bits/shared_ptr.h:1010 #19 makeElement<mu::engraving::Pedal> at /usr/src/debug/musescore-4.2.0-5.fc39.x86_64/src/palette/internal/palettecreator.cpp:94 #20 mu::palette::PaletteCreator::newLinesPalette at /usr/src/debug/musescore-4.2.0-5.fc39.x86_64/src/palette/internal/palettecreator.cpp:1248 #21 mu::palette::PaletteCreator::newMasterPaletteTree at /usr/src/debug/musescore-4.2.0-5.fc39.x86_64/src/palette/internal/palettecreator.cpp:150 #22 mu::palette::PaletteProvider::init at /usr/src/debug/musescore-4.2.0-5.fc39.x86_64/src/palette/internal/paletteprovider.cpp:599 #23 mu::app::App::run at /usr/src/debug/musescore-4.2.0-5.fc39.x86_64/src/app/app.cpp:197
Created attachment 2007772 [details] File: proc_pid_status
Created attachment 2007773 [details] File: maps
Created attachment 2007774 [details] File: limits
Created attachment 2007775 [details] File: environ
Created attachment 2007776 [details] File: open_fds
Created attachment 2007777 [details] File: mountinfo
Created attachment 2007778 [details] File: os_info
Created attachment 2007779 [details] File: cpuinfo
Created attachment 2007780 [details] File: core_backtrace
Created attachment 2007781 [details] File: dso_list
Created attachment 2007782 [details] File: backtrace
note that it doesn't seem reproducible, on another try, I can start it without problem
1. Install musescore-4.2.0-5.fc39.x86_64 via RPM. 2. Run musescore ``` [jonathan@poseidon ~]$ mscore QSocketNotifier: Can only be used with threads started with QThread 11:47:04.234 | INFO | main_thread | GlobalModule::onPreInit | log path: /home/jonathan/.local/share/MuseScore/MuseScore4/logs/MuseScore_240108_114704.log 11:47:04.234 | INFO | main_thread | GlobalModule::onPreInit | === Started MuseScore 4.2.0, build number === 11:47:04.235 | WARN | main_thread | IpcSocket::connect | failed connect to server 11:47:04.235 | WARN | main_thread | IpcSocket::connect | failed connect to server 11:47:04.235 | INFO | main_thread | IpcSocket::connect | success connected to ipc server 11:47:04.235 | INFO | 140382994155200 | IpcServer::listen | id: "8773ed70e68645e8bafbfee0ca3f5332" 11:47:04.276 | WARN | main_thread | DiagnosticsModule::onInit | crash handling disabled 11:47:04.302 | INFO | main_thread | JackAudioDriver::open | clientName: MuseScore 11:47:04.306 | INFO | main_thread | jack_srate_callback | Jack reported sampleRate change. Pray to god, musescores samplerate: 44100, is the same as jacks: 48000 11:47:04.306 | INFO | main_thread | JackAudioDriver::open | buffer size (in samples): 1024 11:47:04.306 | INFO | main_thread | JackAudioDriver::open | sampleRate used by jack: 48000 11:47:04.306 | WARN | main_thread | JackAudioDriver::open | Musescores samplerate: 44100, is NOT the same as jack's: 48000 11:47:04.306 | ERROR | main_thread | MuseSamplerLibHandler::MuseSamplerLibHandler | Unable to open MuseSampler library, path: /home/jonathan/.local/share/MuseSampler/lib/libMuseSamplerCoreLib.so 11:47:04.306 | ERROR | main_thread | MuseSamplerResolver::checkLibrary | Incompatible MuseSampler library; ignoring 11:47:04.306 | ERROR | main_thread | MuseSamplerLibHandler::MuseSamplerLibHandler | Unable to open MuseSampler library, path: libMuseSamplerCoreLib.so 11:47:04.306 | ERROR | main_thread | MuseSamplerResolver::checkLibrary | Incompatible MuseSampler library; ignoring 11:47:04.307 | WARN | main_thread | Qt | QIODevice::read (QFile, "/home/jonathan/.local/share/MuseScore/MuseScore4/shortcuts.xml"): device not open 11:47:04.307 | WARN | main_thread | Qt | QIODevice::read (QFile, "/home/jonathan/.local/share/MuseScore/MuseScore4/midi_mappings.xml"): device not open 11:47:04.309 | WARN | main_thread | AbstractCloudService::readTokens | Could not find the tokens file: /home/jonathan/.local/share/MuseScore/MuseScore4/musescorecom_cred.dat 11:47:04.309 | WARN | main_thread | AbstractCloudService::readTokens | Could not find the tokens file: /home/jonathan/.local/share/MuseScore/MuseScore4/audiocom_cred.dat /usr/include/c++/13/array:211: constexpr const std::array<_Tp, _Nm>::value_type& std::array<_Tp, _Nm>::operator[](size_type) const [with _Tp = mu::engraving::PropertyValue; long unsigned int _Nm = 1433; const_reference = const mu::engraving::PropertyValue&; size_type = long unsigned int]: Assertion '__n < this->size()' failed. Aborted (core dumped) ``` reporter: libreport-2.17.11 type: CCpp reason: mscore killed by SIGABRT journald_cursor: s=3cd2383f4688403ab36c63ac531354a7;i=9a9388;b=5bf09dea2d474aeda5bb5bb17f030ec1;m=4e64b37758;t=60e6dbf384ffa;x=533bf919c6d625f1 executable: /usr/bin/mscore cmdline: /usr/bin/mscore cgroup: 0::/user.slice/user-1000.slice/user/app.slice/app-gnome-org.musescore.MuseScore-150449.scope rootdir: / uid: 1000 kernel: 6.6.8-200.fc39.x86_64 package: musescore-4.2.0-5.fc39 runlevel: N 5 backtrace_rating: 4 crash_function: std::__glibcxx_assert_fail
This crash has also been reported to MuseScore directly, but it does not affect the AppImage distribution: https://github.com/musescore/MuseScore/issues/20878 Seems like something specific to Fedora's build/
I started mscore from the commandline and it crashed immediately. reporter: libreport-2.17.11 type: CCpp reason: mscore killed by SIGABRT journald_cursor: s=218a4f931f0e4e54a2bb3d0db278568e;i=26146;b=e32f3600cfb64080ace2aaeec62d1b33;m=7bfe2316c;t=60eb2f4f3ce63;x=981c74d04acacfc7 executable: /usr/bin/mscore cmdline: /usr/bin/mscore cgroup: 0::/user.slice/user-2815.slice/user/app.slice/app-gnome-org.musescore.MuseScore-37304.scope rootdir: / uid: 2815 kernel: 6.6.9-200.fc39.x86_64 package: musescore-4.2.0-5.fc39 runlevel: N 5 backtrace_rating: 4 crash_function: std::__glibcxx_assert_fail comment: I started mscore from the commandline and it crashed immediately.
I commented on the github issue. I have not yet been able to reproduce this crash. If one of you has a core file that you can upload somewhere, I would love the chance to poke around in its innards.
When starting musescore it crashes reporter: libreport-2.17.11 backtrace_rating: 4 executable: /usr/bin/mscore crash_function: std::__glibcxx_assert_fail rootdir: / reason: mscore killed by SIGABRT runlevel: N 5 package: musescore-4.2.0-5.fc39 comment: When starting musescore it crashes kernel: 6.6.12-200.fc39.x86_64 journald_cursor: s=9eb9a9bf7ca64d5396936178293c4c55;i=2478d5;b=60c436ab21b64076a2e969b0475c587e;m=ca448b36d;t=60fcca3e380a1;x=30b82254b38af7e4 cmdline: /usr/bin/mscore cgroup: 0::/user.slice/user-1000.slice/user/app.slice/app-org.musescore.MuseScore-50afbeca4a49499fbea96441303af95d.scope type: CCpp uid: 1000
FEDORA-2024-236f199386 (musescore-4.2.1-8.fc39) has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-236f199386
The 4.2.1 build has an attempted workaround to avoid this crash. Please try it and let me know if you still encounter the crash. To use the 4.2.1 build successfully, you may need to follow this procedure: - Start MuseScore - Select "Edit", then "Preferences" - Select "Reset preferences" - Quit and restart MuseScore - If desired, open "Preferences" again and customize
FEDORA-2024-236f199386 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-236f199386` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-236f199386 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-236f199386 (musescore-4.2.1-8.fc39) has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
I started MuseScore 4.2.1 reporter: libreport-2.17.11 type: CCpp reason: mscore killed by SIGABRT journald_cursor: s=64e744598b974ffe84052c10d64b00e4;i=4f267d;b=7c224176283a418f89592cdd4035e201;m=2987fd4936;t=61156535ea096;x=eaadec6d33465bcf executable: /usr/bin/mscore cmdline: /usr/bin/mscore cgroup: 0::/user.slice/user-1000.slice/user/app.slice/app-gnome-org.musescore.MuseScore-1993439.scope rootdir: / uid: 1000 kernel: 6.7.4-200.fc39.x86_64 package: musescore-4.2.0-5.fc39 runlevel: N 5 backtrace_rating: 4 crash_function: std::__glibcxx_assert_fail comment: I started MuseScore 4.2.1
About half the times I start musescore, it crashes. Note that I'm starting it with "QT_QPA_PLATFORM=xcb mscore" to work around bug 2250564. reporter: libreport-2.17.11 type: CCpp reason: mscore killed by SIGABRT journald_cursor: s=c9ecd09de5474c328f95e20c15488059;i=eb547;b=3809b902e238491789892d055d65e3ef;m=37b4da5c07;t=611582bc89565;x=8430daacb882e6b8 executable: /usr/bin/mscore cmdline: mscore cgroup: 0::/user.slice/user-2815.slice/user/app.slice/app-org.gnome.Terminal.slice/vte-spawn-1fbefd38-3b18-4ddc-8db7-510b2d94202f.scope rootdir: / uid: 2815 kernel: 6.7.3-200.fc39.x86_64 package: musescore-4.2.0-5.fc39 runlevel: N 5 backtrace_rating: 4 crash_function: std::__glibcxx_assert_fail
The question is whether this is the same assertion failure or a different one. The 2 most recent reports don't give enough information to tell. In any case, I have built a version of MuseScore with the thread sanitizer and am running it locally. It produces a LOT of output. I have started opening pull requests to fix some of these issues. Some have been merged. These are still open: - https://github.com/musescore/MuseScore/pull/21521 - https://github.com/igorkorsukov/kors_profiler/pull/1 There are more data races. I will keep fixing them and sending pull requests as I am able to do so. My hope is that one of these data races is responsible for the assertion failure reported in this bug. If somebody has a better idea of how to track this down, I am all ears.
For what it's worth, I'm not seeing this any more; musescore starts up reliably every time now. I'm on musescore-4.2.1-8.fc39.x86_64.
FEDORA-2024-41a95f1379 (musescore-4.3.0-10.fc39) has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-41a95f1379
FEDORA-2024-fe029d9f84 (musescore-4.3.0-10.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-fe029d9f84
FEDORA-2024-fe029d9f84 has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-fe029d9f84` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-fe029d9f84 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-41a95f1379 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-41a95f1379` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-41a95f1379 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-fe029d9f84 (musescore-4.3.0-10.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-41a95f1379 (musescore-4.3.0-10.fc39) has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.