Quoting the source of dbind_emit_signal_va in dbind/dbind.c, comments
were added by me to explain the situation:
dbind_emit_signal_va (DBusConnection *cnx,
const char *path,
const char *interface,
const char *signal,
const char *arg_types,
dbus_bool_t success = FALSE;
DBusMessage *msg = NULL;
DBusError *err, real_err;
char *p; /* uninitialized pointer, this is going to wreck havoc later */
err = opt_error;
err = &real_err;
msg = dbus_message_new_signal (path, interface, signal);
dbus_message_iter_init (msg, &iter);
dbind_any_marshal_va (&iter, &p, args);
p is now passed down to dbind_any_marshal_va() which segfaults when
dereferencing the pointer in the for-loop.
The obvious fix (to follow the rest of the boilerplate code) would be
to set p to &arg_types before calling dbind_any_marshal_va(),
even better would be to eliminate p altogether.
However, when I do this, at-spi-registryd stops segaulting when I
close applications (this was strangely only triggered by
remove_application() in registry.c), but starts segfaulting when I start
applications, because there is yet another bug in emit() from
emit() seems to omit the arg_types argument to dbind_emit_signal_va()
altogether. I dont quite understand how these different calling
conventions work. dbind_emit_signal_va seems to suggest the idea is to put type
information in a type string, followed by all the arguments. However,
of dbind_emit_signal_va() in emit() from registry.c seems to suggest
there is a
second way where the type information is interlaced with the actual arguments.
I am at a loss how to really fix this correctly.
Fact is the uninitialized pointer in dbind_emit_signal_va needs to be
fixed, and someone needs to look at emit() from registry.c again.
*** This bug has been marked as a duplicate of bug 23027 ***