Cava terminated with SIGSEGV at startup

[somecollagist]

Describe the bug When running cava, the program immediately quits with a SIGSEV (Address boundary error). I have installed this via the AUR and compiled source code locally with the same result.

To Reproduce Just running the program fails.

Expected behavior It shouldn't crash.

Desktop (please complete the following information):

• OS: Arch Linux
• Kernel version: 6.8.7 (though I've had issues on numerous kernel versions before)

Terminal emulator

• Kitty v0.33.1

Additional context

• CPU: Intel i5-1155G7 (with Tigerlake GT2 Iris Xe Graphics)
• Pulseaudio with sof-firmware enabled
• Suprisingly enough, I have no issues with cava when running it on my PC - it has the exact same dotfiles and packages installed, but instead has an AMD Ryzen 5 5600X and Nvidia 3060 GPU.

Stack Trace (from coredump)

#0  0x00007d00a41b919c n/a (libc.so.6 + 0x16a19c)
#1  0x00007d00a40adb09 n/a (libc.so.6 + 0x5eb09)
#2  0x00007d00a40c8276 n/a (libc.so.6 + 0x79276)
#3  0x00007d00a4164a21 __sprintf_chk (libc.so.6 + 0x115a21)
#4  0x000062f1df5b15cf sprintf (cava + 0x135cf)
#5  0x000062f1df5a31e7 main (cava + 0x51e7)
#6  0x00007d00a4074cd0 n/a (libc.so.6 + 0x25cd0)
#7  0x00007d00a4074d8a __libc_start_main (libc.so.6 + 0x25d8a)
#8  0x000062f1df5a7955 _start (cava + 0x9955)

[br1ckw0rm]

Same issue here. Also on kitty and arch

[ghost]

Same. On Arch and Alacritty.

[e4d08]

Same issue. Arch and kitty, too.

[Musheer360]

Same issue, Arch and Kitty.

[0xf8f]

Try to install cava-git package not just cava

[e4d08]

Try to install cava-git package not just cava

Same result for me EDIT: Nevermind, seems to be working now

[karlstav]

not able to reproduce on ubuntu, no update to cava or the cava aur package recently so my guess is that this is coming from somewhere else.

you could try to enable the sanitizer, just in case. Clone and cd into the repo and do:

./autogen.sh
./configure --enable-asan --enable-ubsan 
make clean
make
./cava

[yjinheon]

Same issue, Arch and Kitty.

[chrisjn123]

Same issue here on Arch on 2 different PCs (Intel and AMD w/NVidia)

[somecollagist]

I'm now finding that the AUR package fails to run on both devices (regardless of if I use the cava or cava-git packages). I've compiled from source with and without sanitiser flags on both devices and still get failures unless I have pipewire installed (N.B. libpipewire was already installed as a dependency of mpd), though no output is displayed by the executable. This leads me to consider that there might be an issue in cava finding the correct audio source backend; might be related to #562 ?

Sanitiser logs from cava:

    #0 0x7ad31a28c534 in pw_main_loop_get_loop (/usr/lib/libpipewire-0.3.so.0+0x3a534) (BuildId: 6f5020c872ca6842104cde2e9c1b799dec2f4b2f)
    #1 0x5e7009dda029 in input_pipewire input/pipewire.c:97
    #2 0x7ad3192aa1ce  (/usr/lib/libc.so.6+0x8e1ce) (BuildId: 915eeec6439cfded1125deefc44a8d73e57873d9)
    #3 0x7ad31932b6eb  (/usr/lib/libc.so.6+0x10f6eb) (BuildId: 915eeec6439cfded1125deefc44a8d73e57873d9)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV (/usr/lib/libpipewire-0.3.so.0+0x3a534) (BuildId: 6f5020c872ca6842104cde2e9c1b799dec2f4b2f) in pw_main_loop_get_loop
Thread T1 created by T0 here:
    #0 0x7ad31a448497 in __interceptor_pthread_create /usr/src/debug/gcc/gcc/libsanitizer/asan/asan_interceptors.cpp:208
    #1 0x5e7009d9feab in main /home/johann/Programming/cava/cava.c:457

==824996==ABORTING

[br1ckw0rm]

not able to reproduce on ubuntu, no update to cava or the cava aur package recently so my guess is that this is coming from somewhere else.

you could try to enable the sanitizer, just in case. Clone and cd into the repo and do:

./autogen.sh
./configure --enable-asan --enable-ubsan 
make clean
make
./cava

This fixed the issue I was having.

[karlstav]

we should try to figure out exactly where in the code it crashes.

the first callstack points to a sprintf in main, there are no sprintf in main, but a lot of other printfs. Also a lot of swprintf in the noncurses output. The dump from the sanitizer points to a segfault in pw_main_loop_get_loop in pipewire.

now if you arch people could help me answer one of the following:

1) does it still crash with a different input method? (just try fifo with some fifo (mkfifo)) 2) does it still crash with a different output method? (ncurses, sdl?)

[JonathanSteininger]

The AUR cava segfaults.

Answers to your questions:

1. Using a fifo for input still causes a segfault.

   
               Stack trace of thread 1789271:
               #0  0x0000783fee2ff97a n/a (libc.so.6 + 0xb097a)
               #1  0x0000783fee2af848 n/a (libc.so.6 + 0x60848)
               #2  0x0000783fee2ca693 n/a (libc.so.6 + 0x7b693)
               #3  0x0000783fee36b89f __sprintf_chk (libc.so.6 + 0x11c89f)
               #4  0x000060d3e699e1c5 n/a (/home/Aureus/Packages/cava/src/cava-0.10.1/cava + 0x131c5)
               #5  0x000060d3e69901ec n/a (/home/Aureus/Packages/cava/src/cava-0.10.1/cava + 0x51ec)
               #6  0x0000783fee274d4a n/a (libc.so.6 + 0x25d4a)
               #7  0x0000783fee274e0c __libc_start_main (libc.so.6 + 0x25e0c)
               #8  0x000060d3e6994a05 n/a (/home/Aureus/Packages/cava/src/cava-0.10.1/cava + 0x9a05)
               ELF object binary architecture: AMD x86-64

2. No matter which output It would always segfault. All these were tested with a blank fifo

    ncurses
                Stack trace of thread 1808996:
                #0  0x000074a2df6ff97a n/a (libc.so.6 + 0xb097a)
                #1  0x000074a2df6af848 n/a (libc.so.6 + 0x60848)
                #2  0x000074a2df6ca693 n/a (libc.so.6 + 0x7b693)
                #3  0x000074a2df76b89f __sprintf_chk (libc.so.6 + 0x11c89f)
                #4  0x0000556df97791c5 n/a (/home/Aureus/Packages/cava/src/cava-0.10.1/cava + 0x131c5)
                #5  0x0000556df976b1ec n/a (/home/Aureus/Packages/cava/src/cava-0.10.1/cava + 0x51ec)
                #6  0x000074a2df674d4a n/a (libc.so.6 + 0x25d4a)
                #7  0x000074a2df674e0c __libc_start_main (libc.so.6 + 0x25e0c)
                #8  0x0000556df976fa05 n/a (/home/Aureus/Packages/cava/src/cava-0.10.1/cava + 0x9a05)
                ELF object binary architecture: AMD x86-64
    raw
                Stack trace of thread 1811738:
                #0  0x000079923e4ff97a n/a (libc.so.6 + 0xb097a)
                #1  0x000079923e4af848 n/a (libc.so.6 + 0x60848)
                #2  0x000079923e4ca693 n/a (libc.so.6 + 0x7b693)
                #3  0x000079923e56b89f __sprintf_chk (libc.so.6 + 0x11c89f)
                #4  0x00005f3972b841c5 n/a (/home/Aureus/Packages/cava/src/cava-0.10.1/cava + 0x131c5)
                #5  0x00005f3972b761ec n/a (/home/Aureus/Packages/cava/src/cava-0.10.1/cava + 0x51ec)
                #6  0x000079923e474d4a n/a (libc.so.6 + 0x25d4a)
                #7  0x000079923e474e0c __libc_start_main (libc.so.6 + 0x25e0c)
                #8  0x00005f3972b7aa05 n/a (/home/Aureus/Packages/cava/src/cava-0.10.1/cava + 0x9a05)
                ELF object binary architecture: AMD x86-64
    noritake
                Stack trace of thread 1814304:
                #0  0x00007b07632ff97a n/a (libc.so.6 + 0xb097a)
                #1  0x00007b07632af848 n/a (libc.so.6 + 0x60848)
                #2  0x00007b07632ca693 n/a (libc.so.6 + 0x7b693)
                #3  0x00007b076336b89f __sprintf_chk (libc.so.6 + 0x11c89f)
                #4  0x00005a3b539961c5 n/a (/home/Aureus/Packages/cava/src/cava-0.10.1/cava + 0x131c5)
                #5  0x00005a3b539881ec n/a (/home/Aureus/Packages/cava/src/cava-0.10.1/cava + 0x51ec)
                #6  0x00007b0763274d4a n/a (libc.so.6 + 0x25d4a)
                #7  0x00007b0763274e0c __libc_start_main (libc.so.6 + 0x25e0c)
                #8  0x00005a3b5398ca05 n/a (/home/Aureus/Packages/cava/src/cava-0.10.1/cava + 0x9a05)
                ELF object binary architecture: AMD x86-64
    sdl
                Stack trace of thread 1816348:
                #0  0x0000721b6908a97a n/a (libc.so.6 + 0xb097a)
                #1  0x0000721b6903a848 n/a (libc.so.6 + 0x60848)
                #2  0x0000721b69055693 n/a (libc.so.6 + 0x7b693)
                #3  0x0000721b690f689f __sprintf_chk (libc.so.6 + 0x11c89f)
                #4  0x00005d229299e1c5 n/a (/home/Aureus/Packages/cava/src/cava-0.10.1/cava + 0x131c5)
                #5  0x00005d22929901ec n/a (/home/Aureus/Packages/cava/src/cava-0.10.1/cava + 0x51ec)
                #6  0x0000721b68fffd4a n/a (libc.so.6 + 0x25d4a)
                #7  0x0000721b68fffe0c __libc_start_main (libc.so.6 + 0x25e0c)
                #8  0x00005d2292994a05 n/a (/home/Aureus/Packages/cava/src/cava-0.10.1/cava + 0x9a05)
                ELF object binary architecture: AMD x86-64
    sdl_glsl
                Stack trace of thread 1817736:
                #0  0x000077a3cd87997a n/a (libc.so.6 + 0xb097a)
                #1  0x000077a3cd829848 n/a (libc.so.6 + 0x60848)
                #2  0x000077a3cd844693 n/a (libc.so.6 + 0x7b693)
                #3  0x000077a3cd8e589f __sprintf_chk (libc.so.6 + 0x11c89f)
                #4  0x000056c0f3ddb1c5 n/a (/home/Aureus/Packages/cava/src/cava-0.10.1/cava + 0x131c5)
                #5  0x000056c0f3dcd1ec n/a (/home/Aureus/Packages/cava/src/cava-0.10.1/cava + 0x51ec)
                #6  0x000077a3cd7eed4a n/a (libc.so.6 + 0x25d4a)
                #7  0x000077a3cd7eee0c __libc_start_main (libc.so.6 + 0x25e0c)
                #8  0x000056c0f3dd1a05 n/a (/home/Aureus/Packages/cava/src/cava-0.10.1/cava + 0x9a05)
                ELF object binary architecture: AMD x86-64

noncurses isnt in here because its the default.

Linux bigboi-arch 6.8.7-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 17 Apr 2024 15:20:28 +0000 x86_64 GNU/Linux cpu: Intel Xeon E5-2697 v2

[karlstav]

nice work @JonathanSteininger,

does it crash when compiling from source as well? If so could you try to get some more debug info? You could try configuring with:

CFLAGS="-g -O0" ./configure

that would disable optimization, not sure if we would get where in the source it crashes as well. That would be most useful.

[karlstav]

should be as easy as:

$ gdb ./cava
(gdb) run
<segfault happens here>
(gdb) backtrace
<offending code is shown here>

[Levvonci]

Same issue, Arch and Kitty.

[0xf8f]

Strangely cava package isn't working but cava-git is working. While installling it I encountered a problem when installing cava-git after cava package. Cava-git said it cannot reinstall itself because of cava.debug file in /usr/lib/debug/usr/bin directory. So I managed to delete it by sudo rm and try to reinstall package again and it worked perfectly!

[karlstav]

@somecollagist could you please try to attach gdb debugger as described above so i can find out where in the code it fails? Before this is done there is no way for me to fix this bug as it does not reproduce on my distro and I am not in the mood to install arch at the moment.

[somecollagist]

@karlstav as requested, here's a trace without compiler optimisations. Optimising the build has the same results apart from that the audiodata parameter for the input_pipewire function is optimised out.

[E] pw.loop [loop.c:67 pw_loop_new()] 0x7ffff0000cd0: can't make support.system handle: No such file or directory

Thread 2 "cava" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff5c006c0 (LWP 45683)]
pw_main_loop_get_loop (loop=0x0) at ../pipewire/src/pipewire/main-loop.c:95
95      return loop->loop;                                                                                                                                                                                                          
(gdb) backtrace
#0  pw_main_loop_get_loop (loop=0x0) at ../pipewire/src/pipewire/main-loop.c:95
#1  0x0000555555569817 in input_pipewire (audiodata=0x7fffffffd350) at input/pipewire.c:97
#2  0x00007ffff75b555a in ?? () from /usr/lib/libc.so.6
#3  0x00007ffff7632a5c in ?? () from /usr/lib/libc.so.6

[karlstav]

thanks @somecollagist, here is an actual error message as well, neat. This does not really correspond with @JonathanSteininger findings that it also crashes in fifo input mode though, strange.

Maybe the issue is missing libpipewire package? similar to this

[JonathanSteininger]

This is the backtrace from gdb @karlstav This is using the default configs input method.

#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/strlen-sse2.S:142
#1  0x00007ffff7588848 in __printf_buffer (buf=buf@entry=0x7fffffffadf0, format=0x55555556dcc7 "%s/%s/", ap=0x7fffffffae40, mode_flags=6) at /usr/src/debug/glibc/glibc/stdio-common/vfprintf-process-arg.c:435
#2  0x00007ffff75a3693 in __vsprintf_internal (string=string@entry=0x7fffffffb350 "", maxlen=maxlen@entry=2048, format=<optimized out>, args=args@entry=0x7fffffffae40, mode_flags=mode_flags@entry=6) at iovsprintf.c:62
#3  0x00007ffff764489f in ___sprintf_chk (s=s@entry=0x7fffffffb350 "", flag=flag@entry=2, slen=slen@entry=2048, format=format@entry=0x55555556dcc7 "%s/%s/") at sprintf_chk.c:40
#4  0x00005555555671c5 in sprintf (__fmt=0x55555556dcc7 "%s/%s/", __s=0x7fffffffb350 "") at /usr/include/bits/stdio2.h:30
#5  load_config (configPath=configPath@entry=0x7fffffffca90 "", colorsOnly=colorsOnly@entry=false, error=error@entry=0x7fffffffbe00, p=0x555555576160 <p>) at /usr/src/debug/cava/cava-0.10.1/config.c:410
#6  0x00005555555591ec in main (argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/cava/cava-0.10.1/cava.c:286

This is my coredump when compiled with no optimisation

                Stack trace of thread 2928341:
                #0  0x000078dc39aff97a n/a (libc.so.6 + 0xb097a)
                #1  0x000078dc39aaf848 n/a (libc.so.6 + 0x60848)
                #2  0x000078dc39aca6e8 n/a (libc.so.6 + 0x7b6e8)
                #3  0x000078dc39aaad37 _IO_sprintf (libc.so.6 + 0x5bd37)
                #4  0x0000615b20249352 n/a (/home/Aureus/Packages/cava/src/cava-0.10.1/cava + 0xd352)
                #5  0x0000615b2024287b n/a (/home/Aureus/Packages/cava/src/cava-0.10.1/cava + 0x687b)
                #6  0x000078dc39a74d4a n/a (libc.so.6 + 0x25d4a)
                #7  0x000078dc39a74e0c __libc_start_main (libc.so.6 + 0x25e0c)
                #8  0x0000615b20242005 n/a (/home/Aureus/Packages/cava/src/cava-0.10.1/cava + 0x6005)
                ELF object binary architecture: AMD x86-64

And here is the gdb backtrace with the unoptimised build

#0  __strlen_sse2 () at ../sysdeps/x86_64/multiarch/strlen-sse2.S:142
#1  0x00007ffff7588848 in __printf_buffer (buf=buf@entry=0x7fffffffb140, format=0x555555572493 "%s/%s/", ap=0x7fffffffb190, mode_flags=0) at /usr/src/debug/glibc/glibc/stdio-common/vfprintf-process-arg.c:435
#2  0x00007ffff75a36e8 in __vsprintf_internal (string=<optimized out>, maxlen=maxlen@entry=18446744073709551615, format=<optimized out>, args=args@entry=0x7fffffffb190, mode_flags=mode_flags@entry=0) at iovsprintf.c:62
#3  0x00007ffff7583d37 in __sprintf (s=<optimized out>, format=<optimized out>) at sprintf.c:30
#4  0x0000555555561352 in load_config (configPath=0x7fffffffcab0 "", p=0x55555557baa0 <p>, colorsOnly=false, error=0x7fffffffbe20) at config.c:410
#5  0x000055555555a87b in main (argc=1, argv=0x7fffffffdbf8) at cava.c:286

[JonathanSteininger]

Ok in config.c there is a missing header file not included. But in the git it is.

getenv(char* str) is returning an inacessible address due to the missing header file.

When sprintf is trying to access it the program segfaults.

bool load_config(char configPath[PATH_MAX], struct config_params *p, bool colorsOnly,
                 struct error_s *error) {
    FILE *fp;
    char cava_config_home[PATH_MAX / 2];

    // config: creating path to default config file
    char *configHome = getenv("XDG_CONFIG_HOME");    // uses getenv(char* str) without the header file
    if (configHome != NULL) {
        sprintf(cava_config_home, "%s/%s/", configHome, "cava");  //Crashes here when it tries to access configHome address.
        mkdir(cava_config_home, 0777);
    } else {

The missing header file is

[JonathanSteininger]

So I just checked on the packaged release the header file is missing. But from the git it is included.

All the distribution's repos use the packaged release causing them to break.

[JonathanSteininger]

Need to update release to commit e23ebaf0a9d87cdfe0fe57c40722a66411a18a21 which already fixes this issue.

[JonathanSteininger]

I dont think @somecollagist's segfault backtrace is related to my backtrace. Probably different issues.

[karlstav]

ok , thanks again @JonathanSteininger this clear things up. The missing header is actually the original issue (see stacktrace in first post) . But as @somecollagist started to debug from the actual source code, a completely different issue popped up. So we have two issues:

1) missing stdlib.h include. This was fixed in e23ebaf. (maybe the aur package should enable -Werror to avoid getting in this situation) 2) missing pipewire package, as discussed here

so the issue is that somehow the libpipewire package has been installed, this make cava think that pipewire is available and it compiles with pipewire support also making pipewire default. But other runtime requirements is only in the pipewire package, causing it to crash at startup.

solutions I can think ok: a) check for a runable pipewire on the system in the config scirpt. (compile time) b) make a runtime check for pipewire so it can exit with an error message if it has been built with pipewire support but the system does not actually run pipewire.

leaning towards b), but I fear people will be running here immediately when they get the error message.

[JonathanSteininger]

You could build for all sources that it found and then in runtime try each compiled input.

[karlstav]

could you test the latest commit @somecollagist? It should hopefully exit gracefully instead of segfaulting