mirror of
https://github.com/jpochyla/psst.git
synced 2026-04-27 07:25:52 +03:00
[GH-ISSUE #564] Crash due to dbus name collision #340
Labels
No labels
api
bug
build
documentation
duplicate
enhancement
good first issue
help wanted
idea
invalid
linux
lowprio
macos
pull-request
upstream
windows
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/psst#340
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @CodeF53 on GitHub (Dec 6, 2024).
Original GitHub issue: https://github.com/jpochyla/psst/issues/564
Describe the bug
Environment
Additional context
Add any other context about the problem here.
@jacksongoode commented on GitHub (Dec 9, 2024):
Does this happen reliably? It seems to be triggered by zbus?
@CodeF53 commented on GitHub (Dec 15, 2024):
happened 100% reliably, I uninstalled and reinstalled and it fixed the issue
On Mon, Dec 9, 2024 at 11:37 AM Jackson @.***> wrote:
@SO9010 commented on GitHub (Dec 20, 2024):
The AUR is terribly out of date. Last update in 2022.
@jacksongoode commented on GitHub (Dec 20, 2024):
Can we update that? I feel like the longer term solution is the #170 #141 #530 Flatpak support which was ALMOST finished 😂 but needs a little more of a nudge.
@SO9010 commented on GitHub (Dec 20, 2024):
I can probably update it! I also do want to look more into the flatpak support.
@ernstki commented on GitHub (Dec 21, 2024):
Hi all,
I have
69314f9built in November that exhibited this same problem. The circumstances were a loss of network connectivity when my laptop went into power save mode, with a track playing, and the crash was happening only after initial startup, upon trying to resume a playlist.Backtrace after running
RUST_BACKTRACE=full psst-guiAfter some tinkering, it appears as if just logging out and back in through the app's settings solves this (for now).
I'm not inclined to do anything about it at the moment, in terms of pulling a new version and rebuilding, because otherwise psst is working fine. However, if there's anything else I can do to help isolate which versions of which crates, or reporting a problem to some upstream crate, please let me know.
I do not know a thing about Rust myself, beyond
cargo build, so be gentle.@ernstki commented on GitHub (Dec 21, 2024):
I don't know that much about Arch and the AUR, but I don't think the psst PKGBUILD script builds a specific version, just pulls from GitHub and reports its version as whatever
HEADwas at build time.If
0cd9904from the OP's report is the Git commit ID, then that's from September 2024, a mere 20 commits behind the version I built. Not sure AUR is strictly to blame here is all I'm saying.@omartijn commented on GitHub (Feb 14, 2025):
I'm now also running into this. Tried logging out and logging in again and the problem persisted. This is with latest
mainon a Debian Trixie system. x86_64 architecture.Edit: Actually, just realized this happens when you open a second instance of Psst. The second instance is non-functional.
@winteriscariot commented on GitHub (Mar 12, 2025):
Thanks for this, I ran into this issue cuz I had a zombie psst-gui process that had no gui element and was causing new instances to immediately crash when trying to play a song. killing that orphaned process fixed the issue.
@petermolnar commented on GitHub (Apr 24, 2025):
And indeed, there was a zombie running, which caused my problem as well. Interesting.
@omartijn commented on GitHub (May 2, 2025):
I just realized that the reason this happens to me sometimes is that I have omitted the
StartupWMClass=psst-guioption in my local .desktop file. After adding this, I just get the existing window to the foreground when I try to open psst again.@SO9010 commented on GitHub (May 4, 2025):
Does this fix the issue for others as well?
@ernstki commented on GitHub (May 5, 2025):
Running two instances and then attempting to play in the second instance, while the first one is already playing, seems to cause this crash repeatably. Can the GUI app ensure that there's only one instance of itself running, to maybe avoid this?
I'm
git pulling the current version of the code to see if this still happens. I was running a slightly older build on the workstation I'm using at the moment.Edit: Confirmed, can still reproduce as described above with
78e7dbb, currentmainas of this writing.Backtrace
Let me know if a full backtrace would be helpful.
@SO9010 commented on GitHub (May 5, 2025):
Thank you for this!
Good idea of having a check to see if it's already running...
We could have a simple bool in the config file which is loaded first in the program before the gui is run or anything else.
@ernstki I'll add this hopefully tomorrow and maybe you could try it to see if it fixes it for you? If yes I'll reference the PR to you here!
@ernstki commented on GitHub (May 5, 2025):
@SO9010 Sounds good, and yes I will gladly test for you.
I also experienced a crash in the config parser in updating from whatever version I had checked out to the latest
main. What is the project's policy on having theconfig.jsonbe backwards-compatible?If that sounds like a reportable bug, I'll open a new issue and try to
git bisectfor you to see where the bug first cropped up. Here's a diff of the changes required to avoid the crash, for context. The backtrace, unfortunately, already rolled off the end of my terminal's scrollback buffer.diff -uof original vs. modifiedconfig.json@SO9010 commented on GitHub (May 5, 2025):
Ah yeah, it's not backwards compatible at all! Sorry about that... You can delete it that would fix it, or if you are comfortable with it go through and remove the variables that are causing the issue.
Edit: Just to clarify - are you asking whether using a config file from a newer version of Psst on an older version is supported? If so, unfortunately, it's not!
@ernstki commented on GitHub (May 5, 2025):
OK, I'll still file a bug and close it (linking to your comment), just so a workaround is documented.
I seriously doubt it will be, but if when I'm bisecting there seems like an obvious fix (obvious to not-a-real-Rust-programmer), I'll do a PR for it.
@SO9010 commented on GitHub (May 5, 2025):
We could add the optional field to the deserilizing of that json, but I question how many people use older versions of rust after updating?
But if you want to have a go I'm happy to look through your PR and give some feedback!
@SO9010 commented on GitHub (May 5, 2025):
Update: Found the exact issue with dbus, just need to add a random uid for the dbus name so it doesn't overlap!
Should be a pretty easy fix.
@ernstki commented on GitHub (May 7, 2025):
Insert "there is newer version than Java 8?" meme here. I admit, I always grumble a bit when a toolchain in the LTS Linux repositories is too old to build a project I'm interested in, but I get it. Rust is an evolving language!
Thanks to both of you for having a look at this!