Open Digitalone1 opened 1 year ago
wwmm
commented
1 year ago It's quite reproducible when I have EE window open on a workspace 1 and I switch to workspace 2, pause or seek behind/forward with mpv, then return to the workspace 1 and EE disappeared.
Nothing unusual happens here.
But whenever I open the preset menu I see the following several times:
That is probably related to a gtk update. It started out of nowhere one or two weeks ago.
wwmm
commented
1 year ago I'm using Arch upstream package which is updated to the last release.
I think our AUR pkgbuild does the same that the upstream package. It should not make much difference.
that happens I just see Killed on the command line.
A sign that the system is killing us. I wonder if you are seeing something similar to what happened to rubberband in the pitch shift plugin. The only reason I can think of for the system to be killing us is the plugin realtime thread to be taking "too long" to do its operation. Having the window opened will put more pressure on the CPU. TRy to see if there is anything suspicious in the output of pw-top. Like more errors or higher busy time when the window is opened.
wwmm
commented
1 year ago The only reason I can think of for the system to be killing us is the plugin realtime thread to be taking "too long" to do its operation
But in this case usually the service goes down too. Not only the window... Strange... Maybe the warnings the last gtk update introduced are related to the system killing the extra process that is started when loading the window.
Digitalone1
commented
1 year ago When I have time, I will take a look at pw-top.
wwmm
commented
1 year ago So far no crash here. It feels like the system is killing us in self defense in your machine. The question is if it is related to the plugin realtime thread or some kind of regression in gtk4. What it definitely has. Usually it does not flood our system logs with warnings.
wwmm
commented
1 year ago As expected those warnings are not normal https://gitlab.gnome.org/GNOME/gtk/-/issues/5892. The question is if the next gtk4 update will also fix this weird crash.
wwmm
commented
1 year ago The question is if the next gtk4 update will also fix this weird crash.
The fix for the warnings do not seem deep enough to affect the system killing us. Something else may be going on that is at least to some degree dependent on the hardware.
Something you may try is building EE through the AUR pkgbuild like I usually do and observing if this has any effect. Maybe some kind of problem happened when the official package was created. I will try to test it here.
wwmm
commented
1 year ago I will try to test it here.
It seems fine. So far nothing happens to the window while switching virtual desktops.
wwmm
commented
1 year ago Are you testing the kernel 6.4 release candidates? I am and I've noticed that conky randomly freezes or dies in this kernel. But so far it is the only program I have seen misbehaving in the rc kernel.
wwmm
commented
1 year ago Are you testing the kernel 6.4 release candidates? I am and I've noticed that conky randomly freezes or dies in this kernel. But so far it is the only program I have seen misbehaving in the rc kernel.
Even if you are I remembered now that conky has a segmentation fault in the rc 6.4 kernel and it is not killed by the system.
Digitalone1
commented
1 year ago Meanwhile, testing the null sink volume (that I though it was changing) EE crashed completely, not only the window. Unfortunately I didn't have the console opened. I will test more deeply with debug and pw-top. Just to notice that the issue is still happening...
Digitalone1
commented
1 year ago Are you testing the kernel
6.4release candidates?
No, I'm at 6.3.
redshifttt
commented
1 year ago Having the same issue but on NixOS and an older kernel (6.1.33). I get the same Killed message on the console which never used to happen. When running
$ easyeffectsand pw-top at the same time, pw-top shows that it creates the source then immediately kills it so it could be something possibly related to systemd but more specifically systemd-oomd.
https://asciinema.org/a/58HnGrV2hIDjZPX5wDh6jaOJr
Using strace I found EE being killed with SIGKILL which, according to the systemd-oomd manpage:
If the configured limits are exceeded, systemd-oomd will select a cgroup to terminate, and send SIGKILL to all processes in it.
I believe something may be happening here but I could also be totally wrong; just some observations I had.
wwmm
commented
1 year ago If the configured limits are exceeded, systemd-oomd will select a cgroup to terminate, and send SIGKILL to all processes in it.
This could be related to a plugin taking "too long" to finish its operations in the realtime thread. Try to see if this only happens when a particular choice of plugins is made.
Digitalone1
commented
1 year ago I'm so much busy I hadn't the time to test it yet on pw-top. But anyway I have also another laptop with a more powerful CPU to compare if the app is killed. Will report when I can make it.
Digitalone1
commented
1 year ago Just tried to reproduce it, but nothing. No crash. I can't believe this.
wwmm
commented
1 year ago Just tried to reproduce it, but nothing. No crash. I can't believe this.
These are the worst kind of bug to catch. Probably some kind of multithreading problem if timing is relevant to reproduce the issue.
redshifttt
commented
1 year ago Personally this is the output I get when running G_MESSAGES_DEBUG=easyeffects easyeffects:
It could be related to a plugin but I'm not sure how I would go about disabling them without the GUI but maybe I have overlooked something.
Also the killed message that shows up happens right after the last debug line so there is no hang.
wwmm
commented
1 year ago Based on this https://github.com/wwmm/easyeffects/issues/2419#issuecomment-1603436055 it may be interesting to take a look at the output of sudo journalctl | grep -i easyeffects and search for possible messages about the system killing easyeffects.
redshifttt
commented
1 year ago What I did find interesting was something related to the PID of easyeffects within journalctl. I ran an infinite loop in bash that was just pgrep easyeffects to get the PID so that I could check the journal for the PID and I found this as the latest logs:
$ journalctl -a
...
Jun 24 15:07:18 vesta rtkit-daemon[2184]: Supervising 9 threads of 6 processes of 1 users.
Jun 24 15:07:18 vesta rtkit-daemon[2184]: Supervising 9 threads of 6 processes of 1 users.
Jun 24 15:07:18 vesta rtkit-daemon[2184]: Successfully made thread 40014 of process 39980 owned by '1000' RT at priority 20.
Jun 24 15:07:18 vesta rtkit-daemon[2184]: Supervising 10 threads of 7 processes of 1 users.EE's PID was 39980.
Running the pgrep loop again and again while also running easyeffects over and over again was producing the same result for the PID's of easyeffects so it seems to be related to threading? because right after these messages show up in the journal the program is killed presumably by systemd.
wwmm
commented
1 year ago and I found this as the latest logs
I have these messages too and if I remember well this is normal for any program using rtkit. WE do not use it directly but PipeWire does when setting the plugins thread priority to realtime (SCHED_RR)
redshifttt
commented
1 year ago I have figured out a way to force the program to crash via changing the audio profile. When it's set to Analog Stereo Input (not output, but this allows the window to come up) the window shows up fine and will be responsive but as soon as the profile is changed to the default Analog Stereo Duplex the program crashes.
Here are the logs taken when the program was started with the Analog Stereo Input profile and also when the profile is switched to the default working one plus crash at the end:
Maybe it will shed some light on to things because I haven't found any other way yet to make the program start up.
wwmm
commented
1 year ago Audio/Sink 107 auto_null with serial 1687 has been added
It seems that forcing input only profile on your computer creates a null output sink that is used instead of the soundcard. I am not sure if PipeWire behaves the same way in this situation. I have three soundcards on my computer (2 gpu and the one in the motherboard) but none of them allows an input only profile.
I wish that the kernel or whatever it is killing our process printed clear messages about the reason in the system logs. I still did not see EasyEffects being killed on my computer.
I was testing some presets with media files playing through mpv and noticed this weird issue. The window closes itself randomly.
It's quite reproducible when I have EE window open on a workspace 1 and I switch to workspace 2, pause or seek behind/forward with mpv, then return to the workspace 1 and EE disappeared. Sometimes that happens also when I have EE open without switching workspaces. The service is still running. It's only the window that hides automatically.
Tried to reproduce with G_MESSAGE_DEBUG. When that happens I just see
Killedon the command line. No other errors shown. But whenever I open the preset menu I see the following several times:I'm using Arch upstream package which is updated to the last release. @wwmm try to reproduce and if it's not happening, try to switch to upstream package temporarily, thanks.