On Sun, 03 Mar 2019 at 22:17:24 +0100, Synthea wrote:
> I got more informations while putting my hands randomly on hexchat.
> This bug happens if the following conditions are satisfied:
> 1- Hexchat tries to connect to a server, gets a DNS answer, tries to
> contact the server ip and the server won't answer, but the connection
> attempt won't end either
> 2- The connection attempt is terminated manually (Server > Disconnect)
> 3- Another server is chosen and the connection is successful
> 4- (Not certain but seems in 90% of cases to be related) Hexchat
> receives a message which triggers a dbus notification
> Something makes me suspect that in this particular situation the
> notification method isn't handled correctly, resulting in dbus closing
> the connection
My guess would be that hexchat, or a library or plugin that was loaded
by hexchat, is sending a corrupted D-Bus message. The dbus-daemon responds
to such messages by disconnecting the sender, and GDBus normally responds
to being disconnected by raising SIGTERM.
The most common form of corrupted D-Bus message is a supposedly UTF-8
string (the 's' type) that is not valid UTF-8 - either a valid string
in some non-UTF-8 character set that should have been transcoded to
UTF-8 before sending but was not, or a pointer that is pointing to
uninitialized or freed memory.
A less common form of corrupted D-Bus message is a boolean value
(the 'b' type) with a value other than 0 or 1. This usually happens as
a result of uninitialized or freed memory.
Does hexchat have code that interacts with o.fd.Notifications,
AppIndicator, or a similar D-Bus-based mechanism? Or are you perhaps
using an external plugin that does something similar?
Possible paths towards a solution:
* Run hexchat under valgrind or compile it with AddressSanitizer to check
whether it has a use-after-free bug that can be triggered by a server
not responding to connection attempts
* Check UTF-8 strings for validity before sending
* If the string is in a known non-UTF-8 character set like Latin-1,
transcode it to UTF-8 before sending it in a D-Bus message
* If the "string" is actually an arbitrary byte blob, send it as a
byte-array (D-Bus type 'ay', G_VARIANT_TYPE_BYTESTRING) instead of as
a UTF-8 string (D-Bus type 's', G_VARIANT_TYPE_STRING) - this is only
applicable if you control both ends of the D-Bus communication (if a
standard interface like o.fd.Notifications expects a UTF-8 string,
then that is what you must send)
The GDBusConnection object emits the "closed" signal before raising
SIGTERM, and has an "exit-on-close" property that can be toggled to FALSE
if raising SIGTERM on this class of error is not wanted. However, if
the exit-on-close behaviour is disabled, hexchat will have to be
responsible for exiting when the desktop session ends, for example by
exiting when disconnected from the X11 display or Wayland compositor,
or by watching logind.
> and libdbus-glib killing hexchat
If you're getting a SIGTERM on being disconnected, then that's GDBus,
not dbus-glib. dbus-glib would _exit(1) under the same circumstances
(same idea, different implementation).
smcv
