-
-
Notifications
You must be signed in to change notification settings - Fork 205
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
Blueman applet quit unexpectedly #2201
Comments
The blueman-applet service is dead. So I guess the application isn't running.
I coudn't tell from the GUI if this is the case or not because I even don't know how where and how it's supposed to be. I can systematically reproduce it when I manually turn off bluetooth before turning off my laptop : at reboot the issue happens. I would not call it a harmless exception (as seen in #1241) as I have a notification almost each time I boot, telling me this piece of software has crashed. If it's harmless I shouldn't be bothered with it. The bad thing about it is that there isn't the full Python exception to find out which line of code provokes this error. |
Tried to add '--loglevel DEBUG' to the systemd unit but there aren't more logs in journalctl. It even seems no logs are produced at all. Tried to catch the exception and write the traceback to a file in /tmp by modifying the blueman-applet executable, without any success. I'd like to help to debug this issue but blueman-applet seems hard to debug, sadly (and it's not new according to #459) |
The systemd unit is a dbus service that invokes the application when its well-known name gets addressed on the bus. I'm not familiar with Fedora things, but most probably
The notification is not coming from blueman. It's some Fedora tool, I guess ABRT, that - assuming that it is the harmless exception, originating from a GLib bug - catches things that are not of interest. I don't know how the system is supposed to work, but probably there should be some kind of allowlist either distributed with ABRT or the blueman package that can be used to override such "false positives". Well, in the end it would be an ABRT bug anyway. The tool tells you that blueman-applet quit while it's probably still running, so it's straight up lying to you. What most likely happens is that GLib tries to deliver some event to the application's mainloop and fails to do so. That's why you will not be able to catch anything as it does not happen in our code. It should be catchable in PyGObject code, I guess. Anyway, my guess is that it does not happen in main due to #2009. |
I have been getting what may be a similar error I get the same This issue is usually possible for me to recreate when I pair Samsung Buds Pro 2 earbuds to the system. These earbuds work fine on all my other devices, but since about 1 month ago I cannot get A2DP working on this device. I assumed the error was related to this inability to use a certain profile after I repaired the headphones. |
I think I found a way to reproduce the issue, as I noticed it also happened while updating OS packages. When restarting the bluetooth service with Then when I log-out and log-in again, sometimes the notification appears, sometimes not. But by restarting the bluetooth service I can make it appear once again. It seems that this blueman applet crash occurs if bluetooth service restarts (for any reason) after the applet is loaded in Gnome, like it were a child process also dying when its parent get killed. EDIT: the blueman-applet PID doesn't change when provoking error message by restarting bluetooth service. The process doesn't crash but Gnome thinks it does. This is quite a bit strange. |
I could get some (I hope) interesting logs with
|
I can only repeat what I already wrote: It's #1241 / #620. The application does not crash at all. It's a harmless exception from GLib code. Fedora's ABRT picks it up and lies to you. I assume that's somehow handleable by Fedora's maintainers in their blueman or ABRT packages. It should not happen in our main branch since #2009 changed the code in a way that should not trigger the GLib bug anymore. |
If the main branch has a fix, is there a plan to create a new release soon, so the changes from #2009 and other updates are more widely adopted? |
@engn33r: Sure, it will be contained in 2.4, but there is no schedule. |
Thanks for the information and the work done @cschramm |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
blueman: blueman-1:2.3.5-8.fc39
BlueZ: bluez-5.70-3.fc39.x86_64
Distribution: Fedora 39
Desktop environment: gnome-shell-45.1-1.fc39.x86_64
Blueman applet usually crashes after logon at startup or while updating packages. Could not reproduce the issue by starting it manually in debug mode. The issue happens regularly.
I already opened a Fedora bug here but I've no hope someone is going to look or it over there.
The failure reason is a Python exception regarding UTF-8 decoding but I'm unable to find out where and why. For example:
'utf-8' codec can't decode byte 0xe1 in position 4: invalid continuation byte
There isn't much information in the Fedora "Problem Report" tool.
I'd be more that happy to help finding out the root cause but I can't find where this applet is started and how to enable debug logs to a file.
The text was updated successfully, but these errors were encountered: