Sorry for spamming but this was bothering me so I continued looking into it.
On 25. Juni 2025 7:56 Jan <[email protected]> wrote: > After two or three more wrappers, `notify_notification_show` [4] gets called, > which in turn calls `g_dbus_proxy_call_sync` and tests its return value. So I > added a breakpoint there > > `break 'libnotify/notification.c':1230 commands print result cont end` > > and for one of the parallel threads the result is indeed `$4 = (GVariant *) > 0x0`. I'll follow up when I find more time. Just wanted to document the > current progress. Reading up its documentation, `g_dbus_proxy_call_sync` can provide a verbose error if you give it the opportunity. Alas, usbguard-notifier doesn't care and passes a NULL pointer as `error`. So I instrumented GDB to change this. Due to the multi threading, I had to allocate a pool of memory right at the program start. (GDB fails if you have it call a function and some other thread runs into a breakpoint.) GDB script: ``` set breakpoint pending on break main commands set $MEM=(GError***)((void * (*) (size_t)) malloc) (100*sizeof(GError)) cont end break 'libnotify/notification.c':1124 commands set error=&$MEM[$_thread] set *error=0 cont end break 'libnotify/notification.c':1230 if !result run ``` Extremely hacky but works :-D Once the last breakpoint does trigger, I can finally examine the error reported by libnotifier ```(gdb) print **error $4 = {domain = 182, code = 36, message = 0x7fffe4007750 "GDBus.Error:org.freedesktop.Notifications.Error.ExcessNotificationGeneration: Created too many similar notifications in quick succession"} ``` This makes sense and explains why the bug never triggers when you connect a simple device. A USB hub, on the other hand, comprises multiple USB devices even when none are connected to it yet. So a possible fix would be to use a limiter, distributing the messages over time. Or even better, to actually check the error from libnotifier, wait some (configurable?) time and try again. Regards, Jan
