Bug 2089032

Summary: Rosegarden: crash on startup
Product: [Fedora] Fedora Reporter: Gerry King <trolleybus.1329>
Component: rosegarden4Assignee: Guido Aulisi <guido.aulisi>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 36CC: brendan.jones.it, guido.aulisi, sss
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: rosegarden4-21.12-1.fc36 rosegarden4-21.12-1.fc35 Doc Type: ---
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-06-01 01:23:36 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
mxml patch none

Description Gerry King 2022-05-22 15:07:42 UTC 
Description of problem: 
In Fedora 36, current version of Rosegarden sequencer (21.06.1) crashes on startup producing the following message:

```
GLib (gthread-posix.c): Unexpected error from C library during 'pthread_setspecific': Invalid argument.  Aborting.
```
When run with the `--nosound` key, it runs OK (without any sound, of course).
The problem appeared after updating OS version to 36, on previous versions (34 and 35) the application worked normally.


The newer version from Flathub (21.12) runs as expected. So, the possible solution includes updating the package version to 21.12.


Version-Release number of selected component (if applicable): 21.06.1


How reproducible:



Steps to Reproduce:
1. Install `rosegarden4` package from Fedora repos and PipeWire audio server.
2. Run Rosegarden

Actual results: Rosegarden crashes producing an error message written above.


Expected results: Rosegarden starts up and runs.


Additional info: PipeWire version 0.3.51
Comment 1 Fedora Update System 2022-05-23 06:27:24 UTC 
FEDORA-2022-5f73a11196 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-5f73a11196
Comment 2 Fedora Update System 2022-05-23 06:57:42 UTC 
FEDORA-2022-79df470f4e has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-79df470f4e
Comment 3 Fedora Update System 2022-05-24 01:13:15 UTC 
FEDORA-2022-5f73a11196 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-5f73a11196`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-5f73a11196

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Comment 4 Fedora Update System 2022-05-24 01:15:30 UTC 
FEDORA-2022-79df470f4e has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-79df470f4e`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-79df470f4e

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Comment 5 scott 2022-05-30 21:24:22 UTC 
I think the problem here is actually in mxml.

When it starts up, rosegarden scans for plugins, loading and then unloading
the shared libraries in turn.

At least one, zynaddsubfx-dssi, links against libmxml.

libmxml maintains thread-specific data.  It has an initialization routine
guarded with pthread_once that creates the pthread_key_t.
It also sets up a fini routine with the shared library that destroys
the key again.

The problem is that if the library is unloaded without any functions
having been called, then it will try to destroy the key without
it having been created.  Since the pthread_key_t is stored in a
static variable, it will be calling pthread_key_destroy with key=0.
This destroys a key used by another library entirely, resulting
in a crash when that's later used.

There is a fix in mxml not in the current fedora36 release to correct
a problem with a double-call for the pthread_key_t destructor, but i don't
think that addresses the problem seen here.

The attached patch seems to fix the problem for me.
(It also includes the mxml fix mentioned above.)
Comment 6 scott 2022-05-30 21:26:16 UTC 
Created attachment 1885313 [details]
mxml patch
Comment 7 Fedora Update System 2022-06-01 01:23:36 UTC 
FEDORA-2022-5f73a11196 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.
Comment 8 Fedora Update System 2022-06-01 01:25:36 UTC 
FEDORA-2022-79df470f4e has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.