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
Notification daemon crash when image-path
hint contains an icon name
#7491
Comments
The way things were before: a FreedesktopNotification struct is allocated before the dbus call, and this same struct is possibly re-used for other dbus calls. If the server becomes unavailable, the callback will be invoked after the call times out, which leaves a long time where other dbus calls can happen, re-using the same FreedesktopNotification as user data. When the first call times out, the callback is invoked, and the user data is freed. Subsequent calls that used the same user data will time out later on, and try to free a pointer that was already freed, hence segfaults. This bug can be reproduced in Cinnamon 3.6.7, as mentioned in: <linuxmint/cinnamon#7491> This commit fixes that by always allocating a new FreedesktopNotification before invoking dbus_call(), ensuring that the callback always have a valid user data. Signed-off-by: Arnaud Rebillout <elboulangero@gmail.com>
The way things were before: a FreedesktopNotification struct is allocated before the dbus call, and this same struct is possibly re-used for other dbus calls. If the server becomes unavailable, the callback will be invoked after the call times out, which leaves a long time where other dbus calls can happen, re-using the same FreedesktopNotification as user data. When the first call times out, the callback is invoked, and the user data is freed. Subsequent calls that used the same user data will time out later on, and try to free a pointer that was already freed, hence segfaults. This bug can be reproduced in Cinnamon 3.6.7, as mentioned in: <linuxmint/cinnamon#7491> This commit fixes that by always allocating a new FreedesktopNotification before invoking dbus_call(), ensuring that the callback always have a valid user data. Signed-off-by: Arnaud Rebillout <elboulangero@gmail.com>
@elboulangero are you still experiencing this issue? |
@icarter09 Sorry I found that out only while doing some testing in a Cinnamon VM, after user reported a crash with Goodvibes on Cinnamon. I don't run Cinnamon myself so I can't say. This being said I thing you can try the "Steps to reproduce" above to see if it's still an issue cheers |
@icarter09 Yes it's still an issue here, fedora uses @itzexor WIP to fix it |
Issue
The notification daemon doesn't support icon names.
On the application side, I use GApplication to send notifications. I set an icon using this kind code:
This code will basically crash my application. The crash is due to a bug in glib, which is triggered because the send_notification() times out. It times out because the Cinnamon notification daemon doesn't reply anymore, and probably crashed as well.
I tracked that as much as I could. On the caller side first (ie. glib), we can see that support for GThemedIcon was discussed in Bug 745634, and added in glib ec1edef3.
Now if you look into this file you can see that the implementation will ultimately save the icon in the
image-path
hint. Which leads us to the steps to reproduce...Steps to reproduce
So we can re-create the dbus call that is send by
g_application_send_notification()
. As for the image, we can either use a full path (that's what you get if the caller used GFileIcon), or simply the filename without the extension (that's what you get if the caller used GThemedIcon).Setting a full path works:
Setting an icon name doesn't, there is no notification displayed:
Other information
It's up to you to decide if you want to support Themed Icon or not in your notification daemon, but at least the notification daemon should handle gracefully any junk input that is send by applications in the
image-path
hint.I added some logs in the Cinnamon Javascript, and I ended up here in the file
js/ui/notificationDaemon.js
:This call never returns because
GLib.filename_to_uri
raises an exception that is not handled. I noticed that there's a few of this call in the file, where exceptions are not handled.I added a
try
catch
statement, however the notification is still not displayed. I didn't go further.Hope this helps, feel free to ping me for more details. Cheers,
Arnaud
The text was updated successfully, but these errors were encountered: