Created attachment 1822234 [details] Result of strace -o strace1.txt -f -t -e trace=file mscore Description of problem: I open the preferences window and set the I/O to ALSA so that I can use my USB MIDI keyboard. The MIDI keyboard works after I exit the preferences window. However, when I close and restart MuseScore, it immediately crashes. When I start MuseScore again, a window pops up asking me whether to restore the previous session. If I don't restore the previous session, MuseScore will immediately crash. If I restore the previous session, MuseScore will crash when I create a new score. Version-Release number of selected component (if applicable): 3.6.2-4 How reproducible: It happens every time and I can reproduce it on a new virtual machine. Steps to Reproduce: 1. Install realtime-setup and add yourself to the realtime group 2. In the MuseScore preferences set the I/O to ALSA 3. Close and reopen MuseScore Actual results: MuseScore gets SIGKILL. Expected results: MuseScore doesn't crash. Additional info: dmesg output doesn't seem to have anything related. This only happens when my user has real-time privileges.
Created attachment 1822235 [details] Result of strace -o strace.txt mscore
Created attachment 1822236 [details] Terminal output
Created attachment 1822237 [details] GDB output
We need to figure out what is sending the SIGKILL, and why it is doing so. I wonder if the OOM killer is responsible. Can you make the crash happen again, then immediately run "sudo journalctl"? Then press ">" to go to the end of the log, and see if anything there mentions the SIGKILL.
These are the only lines that appear when I start MuseScore: Sep 11 11:13:16 fedora rtkit-daemon[1176]: Successfully made thread 17431 of process 17431 (/usr/bin/mscore) owned by '1000' high priority at nice level -11. Sep 11 11:13:16 fedora rtkit-daemon[1176]: Supervising 10 threads of 7 processes of 1 users. Sep 11 11:13:16 fedora rtkit-daemon[1176]: Supervising 10 threads of 7 processes of 1 users. Sep 11 11:13:16 fedora rtkit-daemon[1176]: Supervising 10 threads of 7 processes of 1 users. Sep 11 11:13:16 fedora rtkit-daemon[1176]: Successfully made thread 17446 of process 17431 (/usr/bin/mscore) owned by '1000' RT at priority 20. Sep 11 11:13:16 fedora rtkit-daemon[1176]: Supervising 11 threads of 7 processes of 1 users. I have realtime-setup installed and I suspected that it was related to my user being in the realtime group, so I tried adding the test user to the realtime group and I got the crash. Looks like this only happens when the user has real-time privileges.
I'm afraid that I know nothing about realtime-setup. It uses cgroups to manage processes, right? Is it possible that mscore is exceeding some limit set for its group, and that cgroups is killing it as a result? What limits does realtime-setup impose?
I don't know much about realtime-setup either and I just used it to give myself real-time privileges. It adds these lines to /etc/security/limits.d/realtime.conf @realtime soft cpu unlimited @realtime - rtprio 99 @realtime - nice -20 @realtime - memlock unlimited I tried doing this manually without installing realtime-setup on the virtual machine but couldn't reproduce the problem.
> I tried doing this manually without installing realtime-setup on the virtual > machine but couldn't reproduce the problem. Actually, ignore that. Manually adding <user> - rtprio 99 to /etc/security/limits.d/foo.conf without realtime-setup is enough to reproduce the problem. I forgot to add a sound device to the virtual machine earlier.
Is it any different if you launch MuseScore using the AppImage? Download this file, make it executable, and run it. https://github.com/musescore/MuseScore/releases/download/v3.6.2/MuseScore-3.6.2.548021370-x86_64.AppImage The MuseScore developers might have a better idea of what's going on anyway, but especially if you can duplicate the error with the AppImage, then it would be a bug in MuseScore rather than a bug in the RPM packaging scripts.
The upstream AppImage doesn't have this problem but there are some seemingly unrelated issues with pop-up windows sometimes being black.
It's usually because the realtime threads exceed the allowed cpu time and then get killed by the kernel, see man setrlimit and RLIMIT_RTTIME. I'm not sure you can add this to limits.conf but in pipewire we use setrlimit to avoid these sigkills (https://gitlab.freedesktop.org/pipewire/pipewire/-/blob/master/src/modules/module-rt.c#L120).
The output of ulimit -a seems to indicate that the real-time non-blocking time limit for my user is set to unlimited.
I'm now getting SIGKILL with I/O set to jack and default limits (I think). Output of ulimit -a: real-time non-blocking time (microseconds, -R) unlimited core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 63297 max locked memory (kbytes, -l) 8192 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 63297 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.