Application crash when invoking upstart dbus api's.

Tue Jun 9 15:50:00 PDT 2009

Hello,

I am trying to investigate a crash in the dbus/dbus-glib code when
trying to use dbus-glib to communicate with upstart 0.5.

Whenever a crash occurs, it always seems to be failing with a similar
stack trace (see below).

The system is a 4 core cavium board (mips).

The test application is using 4 gthreads to make upstart async api calls
to get upstart version in a while loop.

We have started a separate gthread to that does a g_main_loop_run() to
handle responses from the async calls.

The application crashes after several successful api requests (1000 +)

The same code does not crash on a 2 core ppc based board.

The software versions we are using are as follows.

Upstart     Version   0.5

dbus-glib   Version  0.76

dbus         Version  1.2.1

glib           Version  2.6.6

The code flow looks like this

main()

{

g_type_init ();

g_thread_init(NULL);

dbus_g_thread_init();

//Create dbus connection

connection = dbus_g_bus_get (DBUS_BUS_SYSTEM,&error);

//Create upstart proxy to be shared by the 4 threads.

upstartProxy = dbus_g_proxy_new_for_name (connection,

                                                UPSTART_SERVICE, /*
"com.ubuntu.Upstart"*/

                                                UPSTART_SERVICE_PATH, /*
"/com/ubuntu/Upstart"*/

                                                UPSTART_INTERFACE); /*
"com.ubuntu.Upstart"*/

//Create mutex to lock/unlock before each of the threads makes the async
call.

myMutex=g_mutex_new();

//Upstart Proxy and mutex are passed to all 4 threads.

//Create 1 gthread that runs g_main_loop_run() to handle callbacks for
async calls.

//Create 4 gthreads to make async calls.

//call g_thread_join() on all 5 threads.

}

The code that starts the loopback thread looks like this

void ThreadMainLoop(void *ptr)

{

            GMainLoop *mainloop;

            mainloop = g_main_loop_new (NULL, FALSE);

            g_printf("\nStarting Signal and Async Callback Handler
Thread");

            g_main_loop_run (mainloop);

}

The stack trace looks like this.

Core was generated by `sysmgr_test -ulg 4 -s 1'.

Program terminated with signal 11, Segmentation fault.

#0  0x2d485d94 in _dbus_connection_lock (connection=0x0)

    at /nobackup/spuddupa/nmm32/contrib/dbus/dbus/dbus-connection.c:355

355       CONNECTION_LOCK (connection);

(gdb) bt

#0  0x2d485d94 in _dbus_connection_lock (connection=0x0)

    at /nobackup/spuddupa/nmm32/contrib/dbus/dbus/dbus-connection.c:355

#1  0x2d49f954 in _dbus_pending_call_get_connection_and_lock
(pending=0x1010a978)

    at
/nobackup/spuddupa/nmm32/contrib/dbus/dbus/dbus-pending-call.c:309

------

(gdb) p *(DBusPendingCall *) 0x1010a978

$4 = {refcount = {value = 269547592}, slot_list = {slots = 0x10003fb4,
n_slots = 0}, function = 0, connection = 0x0,

  reply = 0xffffffff, timeout = 0x0, timeout_link = 0x0, reply_serial =
4294967295, completed = 0, timeout_added = 1}

 (gdb) x/16 0x1010a978

0x1010a978:     0x1010f848      0x10003fb4      0x00000000
0x00000000

0x1010a988:     0x00000000      0xffffffff      0x00000000
0x00000000

0x1010a998:     0xffffffff      0x73000000      0x00000000
0x00000011

0x1010a9a8:     0x636f6e6e      0x65637469      0x6f6e0010
0x00000019

------

#2  0x2d48c0ac in reply_handler_timeout (data=0x1010a978)

    at /nobackup/spuddupa/nmm32/contrib/dbus/dbus/dbus-connection.c:3104

---------

(gdb) p *(DBusPendingCall *)data

$21 = {refcount = {value = 269547592}, slot_list = {slots = 0x10003fb4,
n_slots = 0}, function = 0, connection = 0x0,

  reply = 0xffffffff, timeout = 0x0, timeout_link = 0x0, reply_serial =
4294967295, completed = 0, timeout_added = 1}

---------

#3  0x2ce45ddc in timeout_handler_dispatch (data=0x0)

    at /nobackup/spuddupa/nmm32/contrib/dbus-glib/dbus/dbus-gmain.c:343

#4  0x2d1e6e98 in g_timeout_dispatch (source=0x1010f0f0,
callback=0x2ce45db0 <timeout_handler_dispatch>,

    user_data=0x1010b610) at
/nobackup/spuddupa/nmm32/contrib/glib/glib/gmain.c:3293

#5  0x2d1e2a00 in IA__g_main_context_dispatch (context=0x1010c9f8)

    at /nobackup/spuddupa/nmm32/contrib/glib/glib/gmain.c:1934

#6  0x2d1e531c in g_main_context_iterate (context=0x1010c9f8, block=1,
dispatch=1, self=0x1010b610)

    at /nobackup/spuddupa/nmm32/contrib/glib/glib/gmain.c:2565

#7  0x2d1e5808 in IA__g_main_loop_run (loop=0x1010b3b0) at
/nobackup/spuddupa/nmm32/contrib/glib/glib/gmain.c:2769

#8  0x10002cc4 in ThreadMainLoop (ptr=0x0) at
infra/sysmgr/examples/./src/sysmgr_test.c:298

#9  0x2d20b3cc in g_thread_create_proxy (data=0x0) at
/nobackup/spuddupa/nmm32/contrib/glib/glib/gthread.c:561

#10 0x2dfc19e8 in start_thread (arg=0x0) at pthread_create.c:256

#11 0x2e1b0334 in __thread_start () from
/nobackup/spuddupa/nmm32/linkfarm/mips32/lib32/libc.so.6

Backtrace stopped: frame did not save the PC

Am I missing any initialization in the code above?

Is it ok to use the default GMainContext when creating the g_main_loop ?

In most of the examples for g_main_loop I see it being the last
statement of the main program. However I am running it from a gthread.
Is this ok?

Are there any known memory corruption issues that were fixed in newer
releases of dbus and dbus-glib

Any suggestions in debugging this issue would be greatly appreciated.

Note: Will post the same mail on Upstart mailing list as well.

Thanks,

Sandeep

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/dbus/attachments/20090609/50c44c32/attachment-0001.htm 