Bug 23129 - dbind_emit_signal_va calls dbind_any_marshal_va with invalid pointer
Summary: dbind_emit_signal_va calls dbind_any_marshal_va with invalid pointer
Status: RESOLVED DUPLICATE of bug 23027
Alias: None
Product: at-spi2
Classification: Unclassified
Component: core (show other bugs)
Version: unspecified
Hardware: All All
: medium critical
Assignee: Rob Taylor
QA Contact:
Depends on:
Reported: 2009-08-04 03:26 UTC by Mario Lang
Modified: 2009-08-04 08:32 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Description Mario Lang 2009-08-04 03:26:11 UTC
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,
                      DBusError      *opt_error,
                      const char     *arg_types,
                      va_list         args)
    dbus_bool_t success = FALSE;
    DBusMessage *msg = NULL;
    DBusMessageIter iter;
    DBusError *err, real_err;
    char *p; /* uninitialized pointer, this is going to wreck havoc later */

    if (opt_error)
        err = opt_error;
    else {
        dbus_error_init (&real_err);
        err = &real_err;

    msg = dbus_message_new_signal (path, interface, signal);
    if (!msg)
        goto out;

    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,
the call
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.
Comment 1 Mario Lang 2009-08-04 08:32:39 UTC

*** This bug has been marked as a duplicate of bug 23027 ***

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.