wwmm
Easyeffects gets killed by SIGKILL randomly
EasyEffects Version
7.1.6
What package are you using?
Arch (easyeffects)
Distribution
Arch Linux
Describe the bug
On my laptop easyeffects is randomly killed by SIGKILL. Sometimes it get killed 10min after launching, sometimes it takes days. I tried to catch some info, but failed.
strace:
gdb:
I think it's not caused by OOM kill because I didn't experience memory shortage before it got killed.
Expected Behavior
Not get killed, of course.
Debug Log
No response
Additional Information
No response
This may be the system killing our process because the hardware could not keep up with the processing load in the plugins realtime thread. Are there errors in the error column shown by pw-top?
This may be the system killing our process because the hardware could not keep up with the processing load in the plugins realtime thread. Are there errors in the error column shown by
pw-top?
Seems yes
Just one error is not enough to justify a sigkill. Hundreds or thousands of them would make more sense. Which plugins do you have enabled?
Try to see if settings a higher latency on your bluetooth device helps https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Guide-Latency. That quantum value of 512 may be too low for your system.
After changing the quantum value to 1024, the program has not crashed till now.
If this is fixing the problem then the computer not being fast enough to handle all those plugins in the plugins realtime thread seems like the most likely explanation for the system to be killing our process. Not much that can be done other than forcing a higher latency.
This is very strange behaviour. Usually when realtime thread is out of possibility to handle all the stuff, we just get XRuns (buffer overruns or underruns) which introduce clicks or pops into audio but do not affect the whole audio processing pipeline.
This is very strange behaviour. Usually when realtime thread is out of possibility to handle all the stuff, we just get XRuns (buffer overruns or underruns) which introduce clicks or pops into audio but do not affect the whole audio processing pipeline.
At least in the past there was a "maximum allowed run time" configured by PipeWire in the plugins realtime thread. I think that in this case the system can kill a process that reaches the time limit. What is weird is that the limit configured by PipeWire is very high. Probably a few seconds. Even if the system is slow it won't take so long to finish operations.
As weird as it is I can't think of another reason why the system would be sending the sigkill signal to our process. And why a higher latency would be fixing the problem.
I think i7 10750H @4.2GHz is fast enough to process just two audio channels. What about your computer?
It should be. At this moment I have a Ryzen 7700 and before that a Ryzen 3700x. You processor is probably not the problem. I wonder what is the real culprit...
Killed again.
Does this happen only when the window is visible or also while in the background with it hidden?
Might be related to RLIMIT_RTTIME, where if a process exceeds this limit with realtime priority without yielding, the kernel will kill the process. In this case it can be worked around by raising the limit.
Might be related to
RLIMIT_RTTIME, where if a process exceeds this limit with realtime priority without yielding, the kernel will kill the process. In this case it can be worked around by raising the limit.
I think this is what PipeWire sets to a high value.
On my system I get
❯ prlimit --pid (pidof easyeffects)
RESOURCE DESCRIPTION SOFT HARD UNITS
AS address space limit unlimited unlimited bytes
CORE max core file size unlimited unlimited bytes
CPU CPU time unlimited unlimited seconds
DATA max data size unlimited unlimited bytes
FSIZE max file size unlimited unlimited bytes
LOCKS max number of file locks held unlimited unlimited locks
MEMLOCK max locked-in-memory address space unlimited unlimited bytes
MSGQUEUE max bytes in POSIX mqueues 819200 819200 bytes
NICE max nice prio allowed to raise 30 30
NOFILE max number of open files 524288 524288 files
NPROC max number of processes 254509 254509 processes
RSS max resident set size unlimited unlimited bytes
RTPRIO max real-time priority 0 0
RTTIME timeout for real-time tasks 200000 200000 microsecs
SIGPENDING max number of pending signals 254509 254509 signals
STACK max stack size 8388608 unlimited bytes
RTTIME timeout for real-time tasks 200000 200000 microsecs
I have the same value here on my computer. It is not as big as I remembered but 0.2 seconds should be enough time.