musescore / musescore/MuseScore
Unresponsive and high CPU utilization when entering lyrics
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 15.1k
- Forks
- 3.3k
- Avg merge
- 2d 2h
- Merged PRs (30d)
- 91
Description
Issue type
Crash or freeze
Description with steps to reproduce
- Run as Appimage on Debian 12 (stable).
- Enter lyrics in a busy score.
- Observe poor responsiveness and high CPU utilization when pressing "space" to jump to the next note.
Supporting files, videos and screenshots
What is the latest version of MuseScore Studio where this issue is present?
4.3.3, latest master nightly
Regression
I was unable to check
Operating system
Debian 12 (AppImage)
Additional context
I was able to capture what the process was doing with strace during one hangup (after pressing "space" to jump to the next note in the lyrics):
recvmsg(7, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(7, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=18, events=POLLIN}], 4, 0) = 1 ([{fd=6, revents=POLLIN}])
read(6, "\1\0\0\0\0\0\0\0", 16) = 8
recvmsg(7, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
recvmsg(7, {msg_namelen=0}, 0) = -1 EAGAIN (Resource temporarily unavailable)
poll([{fd=6, events=POLLIN}, {fd=7, events=POLLIN}, {fd=8, events=POLLIN}, {fd=18, events=POLLIN}], 4, 9421) = 1 ([{fd=6, revents=POLLIN}])
read(6, "\1\0\0\0\0\0\0\0", 16) = 8
write(6, "\1\0\0\0\0\0\0\0", 8) = 8
poll([{fd=4, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=4, revents=POLLOUT}])
writev(4, [{iov_base="\22\0\7\0$\0\240\3\223\1\0\0\6\0\0\0 \0\0\0\1\0\0\0\304\200\24\5", iov_len=28}], 1) = 28
newfstatat(AT_FDCWD, "/etc/localtime", {st_mode=S_IFREG|0644, st_size=3494, ...}, 0) = 0
write(1, "\33[1;32m02:58:09.200 | INFO | ma"..., 109) = 109
write(15, "2024-08-10T02:58:09.200 | INFO "..., 109) = 109
<PAUSE IS HERE>
memfd_create("unknown-usage:QtQml", MFD_CLOEXEC) = 256
ftruncate(256, 4096) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE, 256, 0) = 0x7fc0c273a000
close(256) = 0
futex(0x7fc12dff1c60, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7fc12dff1c60, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7fc12dff1c60, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7fc12dff1c60, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7fc12dff1c60, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7fc12dff1c60, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7fc12dff1c60, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fc12dff1c60, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fc12dff1c60, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7fc12dff1c60, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7fc12dff1c60, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fc12dff1c60, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7fc12dff1c60, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7fc12dff1c60, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7fc12dff1c60, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fc12dff1c60, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fc12dff1c60, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fc12dff1c60, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fc12dff1c60, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fc12dff1c60, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fc12dff1c60, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7fc12dff1c60, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7fc12dff1c60, FUTEX_WAKE_PRIVATE, 1) = 0
It is also worth noting that the nightly is performing a bit better than the stable 4.3.3 release, but is still noticeably slow and hangs up frequently enough still to be annoying.
Checklist
- This report follows the guidelines for reporting bugs and issues
- I have verified that this issue has not been logged before, by searching the issue tracker for similar issues
- I have attached all requested files and information to this report
- I have attempted to identify the root problem as concisely as possible, and have used minimal reproducible examples where possible
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the slowdown in the MuseScore AppImage on Debian 12 using a busy score and lyrics entry, especially pressing space to move to the next note. Start by profiling the hang and examining the QtQml activity shown in the strace capture. Done means lyrics navigation remains responsive without sustained high CPU usage in both the reported stable and nightly versions.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- desktop, performance
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100