Description of problem: $ timidity -iA -Os Segmentation fault (core dumped) I have an application which depends strongly on the timings of timidity, so using Qsynth and its dependencies instead is only a very bad workaround here. Version-Release number of selected component (if applicable): $ dnf repoquery --installed timidity++ timidity++-0:2.14.0-22.fc34.x86_64 How reproducible: always Steps to Reproduce: see Description Actual results: segfault Expected results: no segfault and running timidity Additional info: Fedora 33 doesn't have this problem The big change from Fedora 33 to Fedora 34 activating pipewire might be relevant here.
Sorry for being slow to respond to this, I just created a backtrace of the crash under gdb and that points to a crash inside alsa-lib; and I cannot find anything wrong with the calling code inside timidity++. Note that the default libao plugin -OO, which uses pulseaudio natively and also the jack plugin -Oj (pipewire also supports jack) both work fine as an alternative. So I believe that you are right that this is somehow caused by the pipewire migration and I'm changing the component of this bug to pipewire.
I'm still hoping this gets sorted out, somehow.
The alsa code is not right, snd_pcm_hw_params_set_rate_near() needs a pointer to the sample rate: This patch might work better: --- TiMidity++-2.15.0.orig/timidity/alsa_a.c 2006-12-14 00:22:56.000000000 +0100 +++ TiMidity++-2.15.0/timidity/alsa_a.c 2021-11-22 09:19:33.852179418 +0100 @@ -380,7 +380,7 @@ dpm.rate = r; ret_val = 1; } - if ((rate = snd_pcm_hw_params_set_rate_near(handle, pinfo, dpm.rate, 0)) < 0) { + if ((rate = snd_pcm_hw_params_set_rate_near(handle, pinfo, &dpm.rate, 0)) < 0) { ctl->cmsg(CMSG_ERROR, VERB_NORMAL, "ALSA pcm '%s' can't set rate %d", alsa_device_name(), dpm.rate);
I wonder if the get_rate_min and and get_rate_max functions are used properly immediately before the line to be changed. According to the ALSA documentation https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.html#gac6c37a5da7dc8cb19fdd8e9cf1bd673d the return values of get_rate_min and get_rate_max is zero if no errors occured I doubt that you should compare the return value with the rate value, these are different things with different semantics. The first if-clause will set a negative dpm.rate to zero. The second if-clause will set a positive dpm.rate to zero. Essentially this will result in a zero dpm.rate if no errors occured. Am I missing something here? 372 /*check rate*/ 373 r = snd_pcm_hw_params_get_rate_min(pinfo, NULL); 374 if (r >= 0 && r > dpm.rate) { 375 dpm.rate = r; 376 ret_val = 1; 377 } 378 r = snd_pcm_hw_params_get_rate_max(pinfo, NULL); 379 if (r >= 0 && r < dpm.rate) { 380 dpm.rate = r; 381 ret_val = 1; 382 } 383 if ((rate = snd_pcm_hw_params_set_rate_near(handle, pinfo, dpm.rate, 0)) < 0) { 384 ctl->cmsg(CMSG_ERROR, VERB_NORMAL, 385 "ALSA pcm '%s' can't set rate %d", 386 alsa_device_name(), dpm.rate); 387 snd_pcm_close(handle); 388 return -1; 389 } I also wonder in case the timestamp 2006-12-14 is correct, the alsa interface has changed meanwhile.
So if the line is changed as in Comment #3 I get the following warning alsa_a.c: In function ‘open_output’: alsa_a.c:383:62: warning: passing argument 3 of ‘snd_pcm_hw_params_set_rate_near’ makes integer from pointer without a cast [-Wint-conversion] 383 | if ((rate = snd_pcm_hw_params_set_rate_near(handle, pinfo, &dpm.rate, 0)) < 0) { | ^~~~~~~~~ | | | int32 * {aka int *} In file included from /usr/include/alsa/pcm.h:937, from /usr/include/alsa/asoundlib.h:54, from alsa_a.c:47: /usr/include/alsa/pcm_old.h:77:104: note: expected ‘unsigned int’ but argument is of type ‘int32 *’ {aka ‘int *’} 77 | unsigned int snd_pcm_hw_params_set_rate_near(snd_pcm_t *pcm, snd_pcm_hw_params_t *params, unsigned int val, int *dir); | BUT according to the ALSA documentation https://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.html#ga39124280d06ce63092a77e3f25ddd6ee this should be (which can be found in pcm.h and not in pcm_old.h) int snd_pcm_hw_params_set_rate_near(snd_pcm_t *pcm, snd_pcm_hw_params_t *params, unsigned int *val, int *dir) Thus I doubt this is the correct fix for the problem. This looks more like some kind of API confusion.
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.
Sorry for being slow in responding to this. I can still reproduce this with F36 so bumping the version of the bug to F36. Now about the actual but itself, as mentioned before the change suggested by Wim Taymans: --- TiMidity++-2.15.0.orig/timidity/alsa_a.c 2006-12-14 00:22:56.000000000 +0100 +++ TiMidity++-2.15.0/timidity/alsa_a.c 2021-11-22 09:19:33.852179418 +0100 @@ -380,7 +380,7 @@ dpm.rate = r; ret_val = 1; } - if ((rate = snd_pcm_hw_params_set_rate_near(handle, pinfo, dpm.rate, 0)) < 0) { + if ((rate = snd_pcm_hw_params_set_rate_near(handle, pinfo, &dpm.rate, 0)) < 0) { ctl->cmsg(CMSG_ERROR, VERB_NORMAL, "ALSA pcm '%s' can't set rate %d", alsa_device_name(), dpm.rate); Does not compile. This is caused by timidity's timidity/alsa_a.c file using: #define ALSA_PCM_OLD_HW_PARAMS_API #define ALSA_PCM_OLD_SW_PARAMS_API #include <alsa/asoundlib.h> But Wim's analysis is correct and we end up in the new version of snd_pcm_hw_params_set_rate_near which expects a pointer not an integer value. I've build alsa-lib from source and installed it as my system alsa-lib with this patch: diff --git a/src/pcm/pcm.c b/src/pcm/pcm.c index 9aec52d1..19b18d7f 100644 --- a/src/pcm/pcm.c +++ b/src/pcm/pcm.c @@ -4777,6 +4777,7 @@ EXPORT_SYMBOL int INTERNAL(snd_pcm_hw_params_set_rate_near)(snd_pcm_t *pcm, snd_ int snd_pcm_hw_params_set_rate_near(snd_pcm_t *pcm, snd_pcm_hw_params_t *params, unsigned int *val, int *dir) #endif { + printf("snd_pcm_hw_params_set_rate_near called, val %p\n", val); return snd_pcm_hw_param_set_near(pcm, params, SND_PCM_HW_PARAM_RATE, val, dir); } @@ -7918,6 +7919,7 @@ EXPORT_SYMBOL ret_type pfx##name(snd_pcm_t *pcm, snd_pcm_hw_params_t *params, re #define __P_OLD_NEAR1(pfx, name, ret_type) \ EXPORT_SYMBOL ret_type pfx##name(snd_pcm_t *pcm, snd_pcm_hw_params_t *params, ret_type val, int *dir) \ { \ + printf("__P_OLD_NEAR1 %s called val %d\n", #name, (int)val); \ if (INTERNAL(name)(pcm, params, &val, dir) < 0) \ return 0; \ return (ret_type)val; \ And then running: "timidity -Os somefile.mid" to reproduce I get: snd_pcm_hw_params_set_rate_near called, val (nil) Segmentation fault (core dumped) Note that the printf in the __P_OLD_NEAR1 wrapper for the 0.9 alsa-lib version of snd_pcm_hw_params_set_rate_near from /usr/include/alsa/pcm_old.h: asm(".symver snd_pcm_hw_params_set_rate_near,snd_pcm_hw_params_set_rate_near"); unsigned int snd_pcm_hw_params_set_rate_near(snd_pcm_t *pcm, snd_pcm_hw_params_t *params, unsigned int val, int *dir); Does not trigger, so something is going wrong with the symbol version stuff since Fedora 34 causing this. I'll try and just port the timidity alsa_a.c code to use the new alsa-lib functions as a quick fix; and I'll file a separate bug for the symbol version issues against alsa-lib.
While filing the alsa-lib bug for this (bug 2087786) I realized that this might be LTO related and indeed adding %global _lto_cflags %nil to timidity++.spec works around this, so I will likely go with this as a workaround for now. Note after the alsa-bug I've also filed a gcc bug, where the symbol-ver vs LTO issues are being discussed in more detail, see bug 2087904.
FEDORA-2022-c982822f2f has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-c982822f2f
FEDORA-2022-c982822f2f has been pushed to the Fedora 37 stable repository. If problem still persists, please make note of it in this bug report.
(In reply to Hans de Goede from comment #8) > While filing the alsa-lib bug for this (bug 2087786) I realized that this > might be LTO related and indeed adding %global _lto_cflags %nil to > timidity++.spec works around this, so I will likely go with this as a > workaround for now. > > Note after the alsa-bug I've also filed a gcc bug, where the symbol-ver vs > LTO issues are being discussed in more detail, see bug 2087904. Would it be possible to get updates for Fedora 35 and Fedora 36? I'm still tied to Fedora 35 at the moment.
FEDORA-2022-df78d56e05 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-df78d56e05
(In reply to a3emdot from comment #11) > Would it be possible to get updates for Fedora 35 and Fedora 36? > I'm still tied to Fedora 35 at the moment. Yes I've already done builds for this and I'm creating the updates in bodhi to get the builds added to the updates-testing repo now.
(In reply to Hans de Goede from comment #13) > (In reply to a3emdot from comment #11) > > Would it be possible to get updates for Fedora 35 and Fedora 36? > > I'm still tied to Fedora 35 at the moment. > > Yes I've already done builds for this and I'm creating the updates in bodhi > to get the builds added to the updates-testing repo now. Thank you Hans for sorting this out and creating the updates. May I ask, how did it occur to you that this might be an LTO problem?
> May I ask, how did it occur to you that this might be an LTO problem? While filing / typing out bug 2087786, this LTO theory based on multiple files including the alsa header just popped into my mind see bug 2087786 comment 1. Note that in the mean time the theory from that comment of why this is a LTO problem has been proven false, but despite that theory being false it really is a LTO issue. Note the F35 bodhi update is here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-9231f67092 For some reason bodhi did not add a comment here about that one.
FEDORA-2022-9231f67092 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-9231f67092` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-9231f67092 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2022-df78d56e05 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-df78d56e05` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-df78d56e05 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Hans de Goede from comment #15) > Note the F35 bodhi update is here: > https://bodhi.fedoraproject.org/updates/FEDORA-2022-9231f67092 > > For some reason bodhi did not add a comment here about that one. I can confirm that under Fedora 35 the segfault is gone. But I would like to mention that due to sound quality issues I will have to stay with QSynth/fluidsynth which I have used as a backup. since Fedora 34. I was hit by this bug, when I was forced to upgrade to Fedora 34. At that time the sound quality using QSynth/Fluidsynth was worse than the sound quality, I was used to with timidity under Fedora 33. using the timidity libao option doesn't help either, which results in cracking noise. Nevertheless I stay with QSynth/fluidsynth and consider this bug as fixed.
FEDORA-2022-9231f67092 has been pushed to the Fedora 35 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2022-df78d56e05 has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report.