Bug 1214798

Summary: musescore - segmentation fault in libQt5Gui.so.5
Product: [openSUSE] openSUSE Tumbleweed Reporter: mekenok hearscrow <turtlevt>
Component: OtherAssignee: Cor Blom <cornelis>
Status: RESOLVED WORKSFORME QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: amajer, balping314, hpj, mvetter, turtlevt
Version: Current   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: mscore file
output from UI test
output from command line with segfault
output from run under gdb

Description mekenok hearscrow 2023-08-30 17:45:02 UTC
Created attachment 869128 [details]
mscore file

musescore segfaults when exporting to a .mp3 file using command line.

Version OS: openSUSE Tumbleweed, Arch.: x86_64, MuseScore version (64-bit): 4.1.1-, revision: github-musescore-musescore-5485621

To reproduce fault:

1. Create test file in musescore and save.

2. Export the test file to .mp3 in musescore using UI - no fault.

3. Export the test file to .mp3 using command line and -o option - segfault

Attachments:

Test-score.mscz - a simple file of C-scale

mscore1 - output of running under UI - no problems

mscore2 - output of running option -o on command line  - segfault

mscore3 - as 2, above but running under gdb for trace - segfault
Comment 1 mekenok hearscrow 2023-08-30 17:46:00 UTC
Created attachment 869129 [details]
output from UI test
Comment 2 mekenok hearscrow 2023-08-30 17:46:50 UTC
Created attachment 869130 [details]
output from command line with segfault
Comment 3 mekenok hearscrow 2023-08-30 17:47:29 UTC
Created attachment 869131 [details]
output from run under gdb
Comment 4 Cor Blom 2023-09-05 11:03:42 UTC
Cannot reproduce.

Works fine here.
Comment 5 mekenok hearscrow 2023-09-05 18:04:19 UTC
I did a zypper dup to update my system.

Operating System: openSUSE Tumbleweed 20230902
KDE Plasma Version: 5.27.7
KDE Frameworks Version: 5.109.0
Qt Version: 5.15.10
Kernel Version: 6.4.12-1-default (64-bit)
Graphics Platform: X11
Processors: 4 × Intel® Core™ i7-7500U CPU @ 2.70GHz
Memory: 15.5 GiB of RAM
Graphics Processor: Mesa Intel® HD Graphics 620
Manufacturer: Dell Inc.
Product Name: Inspiron 15-7579

musescore is 4.1.1-3.1  although mscore -v gives MuseScore4Development 4.1.1-dev

I added some debug files as the segfault persists - although only when using -o on the command line. This is the output from GDB:-

gdb mscore
GNU gdb (GDB; openSUSE Tumbleweed) 13.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-suse-linux".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://bugs.opensuse.org/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from mscore...
Reading symbols from /usr/lib/debug/usr/bin/mscore.debug...
(gdb) run -d -o The_Wild_Colonial_Boy_Lead_sheet_with_lyrics_.mp3 The_Wild_Colonial_Boy_Lead_sheet_with_lyrics_.mscz
Starting program: /usr/bin/mscore -d -o The_Wild_Colonial_Boy_Lead_sheet_with_lyrics_.mp3 The_Wild_Colonial_Boy_Lead_sheet_with_lyrics_.mscz
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff15b86c0 (LWP 6229)]
[New Thread 0x7ffff0db76c0 (LWP 6230)]
[New Thread 0x7fffeb30e6c0 (LWP 6231)]
[New Thread 0x7fffeab0d6c0 (LWP 6232)]
[New Thread 0x7fffea30c6c0 (LWP 6233)]
[New Thread 0x7fffe99e76c0 (LWP 6235)]
[New Thread 0x7fffceb4d6c0 (LWP 6239)]
[New Thread 0x7fffce34c6c0 (LWP 6240)]
[Thread 0x7fffe99e76c0 (LWP 6235) exited]
[Thread 0x7ffff0db76c0 (LWP 6230) exited]
[Thread 0x7fffce34c6c0 (LWP 6240) exited]
[Thread 0x7fffceb4d6c0 (LWP 6239) exited]

Thread 1 "mscore" received signal SIGSEGV, Segmentation fault.
QAccessible::queryAccessibleInterface (object=0x555558fed2b0) at accessible/qaccessible.cpp:727
727             QAccessiblePlugin *factory = qAccessiblePlugins()->value(cn);
Missing separate debuginfos, use: zypper install gvfs-debuginfo-1.50.5-1.2.x86_64 kde-gtk-config5-debuginfo-5.27.7-1.2.x86_64 libFLAC12-debuginfo-1.4.3-1.2.x86_64 

etc, etc, etc...

I know you can not reproduce the fault but does this additional trace and version information help to identify a fault or an inconsistency in my installation?

Is there any further information I can provide to help resolve this.

The problem is not catastrophic, a .mp3 file is correctly produced so I am bringing this only as a minor inconvenience - and out of interest.
Comment 6 Cor Blom 2023-09-05 18:12:45 UTC
This is beyond my skills. I'll add some other maintainers here. Maybe one of them can help.
Comment 7 Adam Majer 2023-09-06 08:03:54 UTC
Probably the easiest is to provide the actual coredump file.

See `coredumpctl` if there is a coredump created. (it's part of systemd-coredump) Then paste the output from that *and* attach the file listed in the Storage: line. There is some documentation here: https://documentation.suse.com/sles/15-SP5/html/SLES-all/cha-tuning-systemd-coredump.html

For example, on my TW system, I just created a sample coredump for `/usr/bin/sleep` and then running `coredumpctl info` (by default it will list the latest)


           PID: 7726 (sleep)
           UID: 1000 (adamm)
           GID: 100 (users)
        Signal: 6 (ABRT)
     Timestamp: Wed 2023-09-06 09:55:39 CEST (2min 22s ago)
  Command Line: sleep 100000
    Executable: /usr/bin/sleep
 Control Group: /user.slice/user-1000.slice/session-3.scope
          Unit: session-3.scope
         Slice: user-1000.slice
       Session: 3
     Owner UID: 1000 (adamm)
       Boot ID: d5fba9b27e7147249510dad451e8e790
    Machine ID: 12fa14a1cc2b4e6c9b04cf8c440d0f04
      Hostname: adamm
       Storage: /var/lib/systemd/coredump/core.sleep.1000.d5fba9b27e7147249510dad451e8e790.7726.1693986939000000.zst (present)
  Size on Disk: 28.7K
       Message: Process 7726 (sleep) of user 1000 dumped core.
                
                Stack trace of thread 7726:
                #0  0x00007f00cb2dacb7 __GI___clock_nanosleep (libc.so.6 + 0xdacb7)
                #1  0x00007f00cb2edb97 __GI___nanosleep (libc.so.6 + 0xedb97)
                #2  0x00005600e760f7a0 n/a (sleep + 0x27a0)
                #3  0x00007f00cb2281f0 __libc_start_call_main (libc.so.6 + 0x281f0)
                #4  0x00007f00cb2282b9 __libc_start_main_impl (libc.so.6 + 0x282b9)
                #5  0x00005600e760f8d5 n/a (sleep + 0x28d5)
                ELF object binary architecture: AMD x86-64


Then I would attach the /var/lib/systemd/coredump/core.sleep.1000.d5fba9b27e7147249510dad451e8e790.7726.1693986939000000.zst file.
Comment 8 mekenok hearscrow 2023-09-06 15:06:06 UTC
I reran the test case:-

/home/turtle/tmp/mscore-diags$ mscore -d -o Test-score.mp3 Test-score.mscz
Segmentation fault (core dumped)

/home/turtle/tmp/mscore-diags$ coredumpctl info
           PID: 5114 (mscore)
           PID: 5114 (mscore)
           UID: 1000 (turtle)
           GID: 100 (users)
        Signal: 11 (SEGV)
     Timestamp: Wed 2023-09-06 10:42:40 EDT (1min 24s ago)
  Command Line: mscore -d -o Test-score.mp3 Test-score.mscz
    Executable: /usr/bin/mscore
 Control Group: /user.slice/user-1000.slice/user@1000.service/app.slice/app-org.kde.konsole\x20\x281\x29-b6>
          Unit: user@1000.service
     User Unit: app-org.kde.konsole\x20\x281\x29-b67d350539454355941b30005740aa3b.scope
         Slice: user-1000.slice
     Owner UID: 1000 (turtle)
       Boot ID: 7212a0de7db24f2f966860d6045adb73
    Machine ID: 12f4692b1f5353b06583b2f957da177a
      Hostname: localhost.localdomain
       Storage: /var/lib/systemd/coredump/core.mscore.1000.7212a0de7db24f2f966860d6045adb73.5114.1694011360>
  Size on Disk: 70.7M
       Message: Process 5114 (mscore) of user 1000 dumped core.
                
                Stack trace of thread 5114:
                #0  0x00007f84c7d23b28 _ZNK5QHashI7QStringP17QAccessiblePluginE5valueERKS0_ (libQt5Gui.so.5>
                #1  0x00007f84c7d44cd3 _ZNK16QAccessibleEvent19accessibleInterfaceEv (libQt5Gui.so.5 + 0x14>
                #2  0x00007f84c7d4520d _ZN11QAccessible19updateAccessibilityEP16QAccessibleEvent (libQt5Gui>
                #3  0x000055b995fd4bc5 _ZN2mu13accessibility23AccessibilityController9sendEventEP16QAccessi>
                #4  0x000055b995fd6272 _ZN2mu13accessibility23AccessibilityController5unregEPNS0_11IAccessi>
                #5  0x000055b995fd6441 _ZN2mu13accessibility23AccessibilityControllerD2Ev (mscore + 0xda644>
                #6  0x000055b9959971ca _ZNSt16_Sp_counted_baseILN9__gnu_cxx12_Lock_policyE2EE19_M_release_l>
                #7  0x00007f84c6e41b26 __run_exit_handlers (libc.so.6 + 0x41b26)
                #8  0x00007f84c6e41c70 __GI_exit (libc.so.6 + 0x41c70)
                #9  0x00007f84c6e281b7 __libc_start_call_main (libc.so.6 + 0x281b7)
                #10 0x00007f84c6e28279 __libc_start_main_impl (libc.so.6 + 0x28279)
                #11 0x000055b995996d05 _start (mscore + 0x766d05)
                
                Stack trace of thread 5115:
                #0  0x00007f84c6f09d2f __GI___poll (libc.so.6 + 0x109d2f)
                #1  0x00007f84c5f16d3e n/a (libglib-2.0.so.0 + 0x5dd3e)
                #2  0x00007f84c5f16e5c g_main_context_iteration (libglib-2.0.so.0 + 0x5de5c)
                #3  0x00007f84c79464a6 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17Proc>
                #4  0x00007f84c78ebffb _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so>
                #5  0x00007f84c7702dce _ZN7QThread4execEv (libQt5Core.so.5 + 0x102dce)
                #6  0x00007f84c9786517 n/a (libQt5DBus.so.5 + 0x1a517)
                #7  0x00007f84c7703ffd n/a (libQt5Core.so.5 + 0x103ffd)
                #8  0x00007f84c6e8ff64 start_thread (libc.so.6 + 0x8ff64)
                #9  0x00007f84c6f1847c __clone3 (libc.so.6 + 0x11847c)
                
                Stack trace of thread 5117:
                #0  0x00007f84c6f1616d syscall (libc.so.6 + 0x11616d)
                #1  0x00007f84c5f703f0 g_cond_wait (libglib-2.0.so.0 + 0xb73f0)
                #2  0x00007f84c5ee0feb n/a (libglib-2.0.so.0 + 0x27feb)
                #3  0x00007f84c5f43572 n/a (libglib-2.0.so.0 + 0x8a572)
                #4  0x00007f84c5f42f2e n/a (libglib-2.0.so.0 + 0x89f2e)
                #5  0x00007f84c6e8ff64 start_thread (libc.so.6 + 0x8ff64)
                #6  0x00007f84c6f1847c __clone3 (libc.so.6 + 0x11847c)
                
                Stack trace of thread 5118:
                #0  0x00007f84c6f09d2f __GI___poll (libc.so.6 + 0x109d2f)
                #1  0x00007f84c5f16d3e n/a (libglib-2.0.so.0 + 0x5dd3e)
                #2  0x00007f84c5f16e5c g_main_context_iteration (libglib-2.0.so.0 + 0x5de5c)
                #3  0x00007f84c5f16ea1 n/a (libglib-2.0.so.0 + 0x5dea1)
                #4  0x00007f84c5f42f2e n/a (libglib-2.0.so.0 + 0x89f2e)
                #5  0x00007f84c6e8ff64 start_thread (libc.so.6 + 0x8ff64)
                #6  0x00007f84c6f1847c __clone3 (libc.so.6 + 0x11847c)
                
                Stack trace of thread 5119:
                #0  0x00007f84c6f09d2f __GI___poll (libc.so.6 + 0x109d2f)
                #1  0x00007f84c5f16d3e n/a (libglib-2.0.so.0 + 0x5dd3e)
                #2  0x00007f84c5f1707f g_main_loop_run (libglib-2.0.so.0 + 0x5e07f)
                #3  0x00007f84c1bdc8c6 n/a (libgio-2.0.so.0 + 0x1228c6)
                #4  0x00007f84c5f42f2e n/a (libglib-2.0.so.0 + 0x89f2e)
                #5  0x00007f84c6e8ff64 start_thread (libc.so.6 + 0x8ff64)
                #6  0x00007f84c6f1847c __clone3 (libc.so.6 + 0x11847c)
                ELF object binary architecture: AMD x86-64


Unfortunately the dump file is larger than allowed for an attachment.
Comment 9 mekenok hearscrow 2023-09-06 15:29:31 UTC
I have uploaded the coredump file to suse ftp server:-

Coredump file uploaded to us.suse.com/incoming

ftp support-ftp.us.suse.com
Trying 3.120.20.211:21 ...
Connected to a25cfcad0e73e4dd9bd0ea8b714f0478-1636996952.eu-central-1.elb.am.
220 Welcome to support-ftp.us.suse.com, powered by SUSE Linux. Please visit https://www.suse.com/company/legal/ for privacy policy
Name (support-ftp.us.suse.com:turtle): anonymous
331 Anonymous login ok, send your complete email address as your password
Password: 
230 Anonymous access granted, restrictions apply
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd incoming
250 CWD command successful
ftp> pwd
Remote directory: /incoming
ftp> bin
200 Type set to I
ftp> prompt off
Interactive mode off.
ftp> put core.mscore.1000.7212a0de7db24f2f966860d6045adb73.5114.1694011360000000.zst
local: core.mscore.1000.7212a0de7db24f2f966860d6045adb73.5114.1694011360000000.zst remote: core.mscore.1000.7212a0de7db24f2f966860d6045adb73.5114.1694011360000000.zst
229 Entering Extended Passive Mode (|||32045|)
150 Opening BINARY mode data connection for core.mscore.1000.7212a0de7db24f2f966860d6045adb73.5114.1694011360000000.zst
100% |*************************************************************************| 72420 KiB  110.56 KiB/s    00:00 ETA
226 Transfer complete
74158463 bytes sent in 10:55 (110.47 KiB/s)
ftp> bye
221 Goodbye.
/var/lib/systemd/coredump$ date
Wed Sep  6 11:27:55 AM EDT 2023
Comment 10 Cor Blom 2023-09-23 09:27:26 UTC
There has been no response for some time and it seems not really a general bug, so I am closing this.