Upstream bug: https://github.com/alsa-project/alsa-lib/issues/281 Applications using ALSA_PCM_OLD_HW_PARAMS_API and/or ALSA_PCM_OLD_SW_PARAMS_API get miscompiled if they are compiled with -flto (GCC link-time optimization (LTO)). See https://bugzilla.redhat.com/show_bug.cgi?id=1910437 and in particular https://bugzilla.redhat.com/show_bug.cgi?id=1910437#c23 . The issue is that the pcm_old.h header uses constructs like: asm(".symver snd_pcm_hw_params_set_rate_near,snd_pcm_hw_params_set_rate_near"); which do not seem to work with LTO enabled. Maybe this needs to use the symver attribute instead? In any case, what happens is that the caller in the application attempts to call the new function snd_pcm_hw_params_set_rate_near.0rc4 with the ABI of the old one snd_pcm_hw_params_set_rate_near, so an integer is passed where ALSA expects a pointer, leading to a segfault (or worse). The workaround is to compile the application without LTO enabled (which makes it work fine), but I believe that this is an upstream ALSA issue and should be fixed in the ALSA header files.
I cannot confirm. Trying code https://raw.githubusercontent.com/alsa-project/alsa-lib/master/test/oldapi.c: $ gcc -flto -lasound -o oldapi oldapi.c $ nm oldapi | grep get_access U snd_pcm_hw_params_get_access So .symver does work as expected. Also checked the snd_pcm_hw_params_set_rate_near function. Also, I don't know other way to to tell gcc which symbol is wanted. The symver function attribute is for the function definition (code in the library). It cannot be used in the header files (we need to keep the .symver asm code).
Well, this build was built with -flto: https://koji.fedoraproject.org/koji/buildinfo?buildID=2006641 and this is the same without -flto: https://koji.fedoraproject.org/koji/buildinfo?buildID=2085617 If you download the RPMs, extract libartsflow.so.1.0.0 from each, and run nm -D on them, you will see (as I have) that the build with -flto imports: U snd_pcm_hw_params_set_rate_near whereas the build without -flto imports: U snd_pcm_hw_params_set_rate_near.0rc4 I can also tell you that arts-1.5.10-49.fc35 (built with -flto) crashed on my system and arts-1.5.10-54.fc35 (built without -flto) works.
> If you download the RPMs, extract libartsflow.so.1.0.0 from each, and run nm -D on them, you will see (as I have) that the build > with -flto imports: > U snd_pcm_hw_params_set_rate_near > whereas the build without -flto imports: > U snd_pcm_hw_params_set_rate_near.0rc4 Sorry, it is the other way round: If you download the RPMs, extract libartsflow.so.1.0.0 from each, and run nm -D on them, you will see (as I have) that the build without -flto imports: U snd_pcm_hw_params_set_rate_near (which is correct) whereas the build with -flto imports: U snd_pcm_hw_params_set_rate_near.0rc4 (which is incorrect).
> Also, I don't know other way to to tell gcc which symbol is wanted. The symver function attribute is for the function definition (code in the library). It cannot be used in the header files (we need to keep the .symver asm code). Looks like GCC needs to be fixed then.
> gcc -flto -lasound -o oldapi oldapi.c Maybe try gcc -O2 -flto …? Default is -O0 which might not exhibit the issue. Real-world builds always use -O2.
> Maybe try gcc -O2 -flto …? Default is -O0 which might not exhibit the issue. Real-world builds always use -O2. Tried -O2 and -O3 - no difference. > Sorry, it is the other way round: It may be something when two shared LTO libraries links together. But libasound.so offers both symbols, so I would look to fix this issue in the arts linking commands. And I don't see this problem when I try to link libatopology.so with libasound.so with this test code when I am building alsa-lib from the source tree (directly): diff --git a/src/topology/ctl.c b/src/topology/ctl.c index dd05424d..caab34f9 100644 --- a/src/topology/ctl.c +++ b/src/topology/ctl.c @@ -20,6 +20,9 @@ #include "list.h" #include "tplg_local.h" +//#define ALSA_PCM_OLD_HW_PARAMS_API +//#include "pcm_old.h" + #define ENUM_VAL_SIZE (SNDRV_CTL_ELEM_ID_NAME_MAXLEN >> 2) struct ctl_access_elem { @@ -71,7 +74,7 @@ static int parse_access_values(snd_config_t *cfg, } } } - + return snd_pcm_hw_params_get_access(NULL); return 0; } $ nm src/topology/.libs/libatopology.so | grep get_access U snd_pcm_hw_params_get_access.0rc4 With removed comment identifiers '//' to activate the old symbol: $ nm src/topology/.libs/libatopology.so | grep get_access U snd_pcm_hw_params_get_access Compile command: gcc -DHAVE_CONFIG_H -I. -I../../include -I../../include -O2 -Wall -W -Wunused-const-variable=0 -pipe -g -flto -flto-partition=none -MT ctl.lo -MD -MP -MF .deps/ctl.Tpo -c ctl.c -fPIC -DPIC -o .libs/ctl.o The "-flto-partition=none" option may be removed - same result.
And the linking command for the completness: gcc -shared -fPIC -DPIC .libs/parser.o .libs/builder.o .libs/ctl.o .libs/dapm.o .libs/pcm.o .libs/data.o .libs/text.o .libs/channel.o .libs/ops.o .libs/elem.o .libs/save.o .libs/decoder.o .libs/log.o -Wl,-rpath -Wl,/home/perex/alsa/alsa-lib/src/.libs ../.libs/libasound.so -lm -ldl -lpthread -lrt -O2 -g -flto -Wl,--version-script=../Versions -Wl,-z -Wl,defs -Wl,-soname -Wl,libatopology.so.2 -o .libs/libatopology.so.2.0.0
Weird. Sounds more and more like a toolchain bug, shall I reassign it to gcc?
Yes, gcc seems more appropriate for this issue.
This bug appears to have been reported against 'rawhide' during the Fedora Linux 38 development cycle. Changing version to 38.
This message is a reminder that Fedora Linux 38 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 38 on 2024-05-21. 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 '38'. 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. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see it. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 38 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 38 entered end-of-life (EOL) status on 2024-05-21. Fedora Linux 38 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 Linux please feel free to reopen this bug against that version. Note that the version field may be hidden. Click the "Show advanced fields" button if you do not see the version field. If you are unable to reopen this bug, please file a new report against an active release. Thank you for reporting this bug and we are sorry it could not be fixed.