-
-
Notifications
You must be signed in to change notification settings - Fork 52
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
Segfault if ipc requests sent too rapidly #45
Comments
Is there a temporary workaround to this problem? I switch wallpapers pretty frequently since I have a different one for each workspace, and |
try with 3596630 |
Now we die normally:
The particular serial changes so it could be memory corruption. If you tell me what to set a breakpoint on I'll see if I can get a proper backtrace. This was a segfault before and I couldn't reproduce this time, so I think the segfault is cured, even if the problem has just moved. |
You can set it up to restart e.g. with systemd. I think there's an example in the linked issue. OTOH I don't have any noticeable crashes with the script above ticking every 5 minutes after adding a delay and a lock: from time import sleep
from filelock import FileLock
lock = FileLock("/tmp/hyprpaper.lock")
def load_backgrounds(mapping: dict[str, Path]):
with lock:
# as above
sleep(0.5) No need to use python if you don't want to, this is trivial in e.g. bash. Using a file lock might be the trick if you're flipping between workspaces fast enough to get there before hyprpaper has settled down from the last switch. |
I think there's a race condition here:
The I'm not sure how can we solve this. Even setting the configuration serial as atomic doesn't mitigate this problem. |
Arrived here via search for the issue after i experienced it by accidentally hitting the [1] key when switching to workspace 2 by pressing [Super]+[2]. So by following the Hyprland wiki to set up different wallpapers for each workspace and then cycle them too fast: crash. The claim "Hyprpaper is a blazing fast wallpaper utility" seems a bit weird given that this issue happens when you "switch too fast" ... 😅 Right now i use a script to subscribe to the Hyprland socket and only switch the wallpapers after a timeout during which no workspace change happens. It works but doesn't feel "blazing fast" tbf. //edit:
For configuration it expects a wallpapers.json in the same directory (see config vars) in this format:
Replace the array keys with your workspace names.. special workplaces work too.. //edit2: |
Has the issue been fixed? I recently updated my hyprpaper to 0.7.0 and rapid switching no longer crashes it. |
If I send ipc requests too rapidly, hyprpaper segfaults in a variety of places (curiously, often in
vnsprint
), or gets a bus error.I have a script to load a random wallpaper:
If I run this in a loop at the terminal it will segfault after ~3 iterations. If I add a sleep, i.e.
I can control the behaviour somewhat. With 0.5 it dies only occasionally, and usually with sigbus. With 0.1 it segfaults pretty quickly. Obviously looping over wallpapers isn't very useful, but I can't guarantee that a user won't hit the 'reload' button in quick succession.
For the time being I can work around it with a file lock. Should the socket code block until the load operation is finished?
version
Latest master with my case-insensitive patch, i.e. 0a85097
The text was updated successfully, but these errors were encountered: