Bug 23027 - at-spi-registryd dumps core when an application registers
Summary: at-spi-registryd dumps core when an application registers
Alias: None
Product: at-spi2
Classification: Unclassified
Component: core (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Mark Doffman
QA Contact:
: 23129 (view as bug list)
Depends on:
Reported: 2009-07-29 14:37 UTC by Willie Walker
Modified: 2009-08-06 12:07 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:

Patch to initialize parameter being sent to dbind_any_marshal_va (345 bytes, patch)
2009-07-29 14:37 UTC, Willie Walker
Details | Splinter Review

Description Willie Walker 2009-07-29 14:37:44 UTC
Created attachment 28173 [details] [review]
Patch to initialize parameter being sent to dbind_any_marshal_va

Using the at-spi2-core and at-spi2-atk code from git master, I run the at-spi-registryd in one shell and another application (gcalctool) in another shell.  As soon as I run gcalctool, the at-spi-registryd dumps core.  Here's a debug trace:

(dbx) where
=>[1] dbind_any_marshal_va(iter = 0x8047660, arg_types = 0x8047648, args = 0x80476e4), line 356 in "dbind-any.c"
  [2] dbind_emit_signal_va(cnx = 0x80961e8, path = 0x805bf5c "/org/freedesktop/atspi/registry", interface = 0x805bf7c "org.freedesktop.atspi.Registry", signal = 0x805bf9c "updateApplications", opt_error = (nil), arg_types = 0x69 "<bad address 0x69>", args = 0x80476e4), line 180 in "dbind.c"
  [3] emit(reg = 0x8098320, itf = 0x805bf7c "org.freedesktop.atspi.Registry", name = 0x805bf9c "updateApplications", ftype = 105, ... = 0x80476fc, ...), line 62 in "registry.c"
  [4] add_application(bus = 0x80961e8, reg = 0x8098320, app = 0x809de9c ":1.186"), line 138 in "registry.c"
  [5] impl_registerApplication(bus = 0x80961e8, message = 0x809de20, user_data = 0x8098320), line 196 in "registry.c"
  [6] handle_other(bus = 0x80961e8, message = 0x809de20, path = 0x8095348, iface = 0x809df30 "org.freedesktop.atspi.Registry", member = 0x809df58 "registerApplication", pathstr = 0x809dee0 "/org/freedesktop/atspi/registry"), line 494 in "droute.c"
  [7] handle_message(bus = 0x80961e8, message = 0x809de20, user_data = 0x8095348), line 534 in "droute.c"
  [8] _dbus_object_tree_dispatch_and_unlock(0x808d3b0), at 0xfd4d4fc3 
  [9] dbus_connection_dispatch(0x80961e8), at 0xfd4c7517 
  [10] message_queue_dispatch(0x8095ea0, 0x0, 0x0, 0xfd402714), at 0xfef59f41 
  [11] g_main_context_dispatch(0x80946e8, 0x0, 0x808d578, 0x2), at 0xfd4028da 
  [12] g_main_context_iterate(0x80946e8, 0x1, 0x1, 0x80960b8), at 0xfd402f7d 
  [13] g_main_loop_run(0x808d380, 0x0), at 0xfd4035f1 
  [14] main(argc = 1, argv = 0x8047a98), line 130 in "registry-main.c"

In digging into this, I notice the following:

* at-spi2-core/registryd/registry.c:emit calls dbind_emit_signal_va.  The penultimate parameter is 'ftype', which is an int.

* at-spi2-core/dbind/dbind.c:dbind_emit_signal_va expects a 'const char *arg_types' instead of the int ftype being passed to it.  This is kind of a red herring, though, because arg_types isn't used in this method.

* This same dbind_emit_signal_va method, however, creates an uninitialized 'char *p' that it then sends to at-spi2-core/dbind/dbind-any.c:dbind_any_marshal_va.  dbind_any_marshal_va seems to assume it will be initialized to something, and this seems to be the source of the problem.

The attached patch initializes "*p" to the empty string and seems to solve the crash. I've no idea if this is the right thing to do, though.
Comment 1 Mario Lang 2009-08-04 08:32:39 UTC
*** Bug 23129 has been marked as a duplicate of this bug. ***
Comment 2 Mark Doffman 2009-08-06 12:07:10 UTC
I have added a check to dbind_marshal_any for empty signatures. This should work for method calls also. This was added in commit 8a8a60bbdd195d8e50a538b050a551443e47a6c2.

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.