Application crash when invoking upstart dbus api's.

Ville M. Vainio vivainio at gmail.com
Wed Jun 10 08:49:51 PDT 2009


On Wed, Jun 10, 2009 at 6:31 PM, Sandeep Puddupakkam
(spuddupa)<spuddupa at cisco.com> wrote:

> The program I am running is doing a stress test.
>
> 4 threads (configurable number from command line) are making the upstart
> sync/asyncapi (upstart_get_version()) calls. 1 separate thread is running
> the g_main_loop_run() to handle responses from the async calls.

If you are doing stress tests for upstart (as opposed to dbus),
eliminate the dbus race condition issue by stressing the server from
different processes.

> The fact that connection is null after several api calls leads me to think
> there is some memory corruption happening.
>

I have experienced several crashes in reply_handler_timeout. See
comments my comments on that dbus defect I posted.

The deal with dbus is that it's currently not thread safe for certain
usage patterns (which will appear to work on certain timing
conditions). If you are stressing dbus from multiple threads, it may
be wise to avoid dbus_connection_send_with_reply.

-- 
Ville M. Vainio
http://tinyurl.com/vainio


More information about the dbus mailing list