-
-
Notifications
You must be signed in to change notification settings - Fork 264
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
App window closes itself without user intervention #2407
Comments
Nothing unusual happens here.
That is probably related to a gtk update. It started out of nowhere one or two weeks ago. |
I think our AUR pkgbuild does the same that the upstream package. It should not make much difference.
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 |
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. |
When I have time, I will take a look at |
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. |
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. |
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. |
It seems fine. So far nothing happens to the window while switching virtual desktops. |
Are you testing the 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. |
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 |
No, I'm at 6.3. |
Having the same issue but on NixOS and an older kernel (6.1.33). I get the same
and https://asciinema.org/a/58HnGrV2hIDjZPX5wDh6jaOJr Using
I believe something may be happening here but I could also be totally wrong; just some observations I had. |
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. |
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. |
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. |
Personally this is the output I get when running Debug flag output
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. |
Based on this #2419 (comment) it may be interesting to take a look at the output of |
What I did find interesting was something related to the PID of easyeffects within
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. |
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) |
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: Debug Output
Maybe it will shed some light on to things because I haven't found any other way yet to make the program start up. |
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
Killed
on 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.
The text was updated successfully, but these errors were encountered: