Pulseffect 5.0.1-1 crashes on i3wm when getting unfocussed

[s-iso]

The application runs perfectly until I click somewhere else (take away focus from it), at which point it just straight out crashes.

I'm running arch linux with pipewire and i3wm + xorg.

This effect only seems to happen when an audio stream is actively running / being processed. No error messages when running from console.

[s-iso]

Addendum: This behavior doesn't happen with Pulseffects 5.0.0-1

[wwmm]

I am suspecting that updates done to the gtk3 and gtkmm3 packages in the Arch repositories in the last weeks are a little unstable. I have seen random crashes in PulseEffects that feel like a problem in the graphical toolkit.

The application runs perfectly until I click somewhere else (take away focus from it), at which point it just straight out crashes.

We do nothing when the focus is changed. I do not see what I could do different. Specially considering that in GNOME nothing happens when switching focus by clicking somewhere else. That is why I think the issue is somewhere in the gtk3 or gtkmm3 packages.

In any case it might be helpfull to see the logs. Kill the current instance pulseeffects -q and restart it in debug mode G_MESSAGES_DEBUG=pulseeffects pulseeffects

[chezbgone]

This was happening to me, and I fixed it by clicking the reset settings button in general tab. (Be sure to save a preset before resetting.) The next time I opened Pulseffects, it stopped crashing.

[ppascher]

Had the same issue using sway/wlroots with pipewire-git. Resetting pulseeffects as mentioned by @chezbgone fixed it for me as well.

[chezbgone]

I changed the Priority Type to Real Time, and it started to happen again. Reverting the setting fixes it, so I'm inclined to believe this is the cause.

[viraptor]

I'm digging a bit into the reasons this happens - I'll dump some info as I go:

• not sure where the SIGKILL comes from yet
• the stacktraces (not sure why they're partial - obtained using bpftrace) in the app when the SIGKILL comes in are:

- thread
poll + 79 in section .text of /lib64/libc.so.6

- thread
gtk_css_value_corner_compute.lto_priv + 199 in section .text of /lib64/libgtk-3.so.0
(unknown)
gtk_css_value_dimension_compute.lto_priv in section .text of /lib64/libgtk-3.so.0
(unknown)

- 4 threads
epoll_wait + 94 in section .text of /lib64/libc.so.6
loop_iterate + 164 in section .text of /usr/lib64/spa-0.2/support/libspa-support.so
impl_get_interface.lto_priv in section .text of /usr/lib64/spa-0.2/support/libspa-support.so

The user stack bpf claims is active when the signal is generated is:

gtk_css_animated_style_create_css_transitions.constprop + 770 in section .text of /lib64/libgtk-3.so.0

But that doesn't really make much sense to me so far...

[viraptor]

I've got some progress. After eliminating the userspace failures (everything seems to be happy and nothing calls kill() explicitly), I started digging into kernel stack, which looked like:

        __send_signal+582
        __send_signal+582
        posix_cpu_timers_work+286
        task_work_run+101
        exit_to_user_mode_prepare+385
        irqentry_exit_to_user_mode+5
        asm_sysvec_apic_timer_interrupt+18

Digging into the posix_cpu_timers_work function and possible places where it causes a signal to be sent, I found it's in check_rlimit https://elixir.bootlin.com/linux/latest/source/kernel/time/posix-cpu-timers.c#L812
The function doesn't show up on the list, because we're 3 levels deep in inlined code.

Anyway, the reason there was no logs is because most systems run with kernel.print-fatal-signals sysctl set to 0. After running sysctl kernel.print-fatal-signals=1 we get the real failure reason:

May 30 11:37:59 harmless kernel: RT Watchdog Timeout (hard): pulseeffects[22407]

While pulseeffects starts with no limits, as soon as audio processing starts, the hard limit is changed to 200000 μ.

For some reason when the audio stops and the app loses the audio stream, the delay is large enough that the watchdog is triggered in kernel's task scheduling and kills the process immediately.

I'm not sure if this is related to focus itself, but it's definitely happening when the audio stream stops.

[wwmm]

Interesting. So that is what is going on. My guess is that we should ask for a different RLIMIT_RTTIME value at https://github.com/wwmm/pulseeffects/blob/1253ceff3a0a23618f73af89c10d80f7a19b1476/src/realtime_kit.cpp#L139. What we do now is asking for RTTimeUSecMax. But I think that if this value was not allowed anymore setrlimit should fail. It does not seem it does. Strange...

In any case we won't have to bother with this in our gtk4 branch. PipeWire will be the one handling the realtime priorities of the plugins threads and not us.

[viraptor]

Sounds good. Also, I don't think the strict setting right now is really needed.
https://github.com/wwmm/pulseeffects/blob/1253ceff3a0a23618f73af89c10d80f7a19b1476/src/realtime_kit.cpp#L142
sets both the hard and soft limit, but for sound processing the hard limit is not really needed in most cases. Handling the signal on the soft limit to print a "your processing is too slow" message could be a nicer result than a crash.

[wwmm]

Fixed in EasyEffects 6.0.0