[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-dbus
Subject:    Re: Application crash when invoking upstart dbus api's.
From:       "Ville M. Vainio" <vivainio () gmail ! com>
Date:       2009-06-10 15:49:51
Message-ID: 46cb515a0906100849j2fcf91c3nb6b3846fc6609b15 () mail ! gmail ! com
[Download RAW message or body]

On Wed, Jun 10, 2009 at 6:31 PM, Sandeep Puddupakkam
(spuddupa)<spuddupa@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
_______________________________________________
dbus mailing list
dbus@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dbus
[prev in list] [next in list] [prev in thread] [next in thread]