dbus_shutdown call

Ge@@ru geaaru at gmail.com
Wed Jan 9 07:52:28 PST 2008


For my opinion is a bug! :P

Infact, on amd64 (gentoo) environment a sigabrt is handled and sure this
isn't a fine end of my process! :)

Thanks for your help!

Ge@@ru

On Wed, 2008-01-09 at 17:37 +0200, Naveen Verma wrote:
> Hi,
> 
> I was trying to browse the libdbus code, for this issue. I found
> library stores the new shared connection in the hash table on the
> basis of guid and dbus_shutdown check the hash table to close the
> shared connection. Since default system bus does not have guid so it
> does not get stored and dbus_shutdown does not find it. But later
> address deleting function check for open connection connection at the
> system bus address, and since its not closed so it give the error
> message which we are discussing. 
> 
> But I did not understand whether it is a bug or feature that is any
> application should not be able to close the shared connection with the
> system bus?
> 
> -Br
> Naveen
> 
> On Jan 9, 2008 3:11 PM, Ge@@ru < geaaru at gmail.com> wrote:
>         Yes, on debian environment (32bit x86), exit normally but i
>         have same 
>         message error about dbus_shutdown:
>         
>         [easydbus.c at easydbus_deinit:64] Deinit EasyDbus 0.1 library...
>         process 2558: dbus_shutdown() called but connections were
>         still live.
>         This probably means the application did not drop all its
>         references to 
>         bus connections.
>         
>         
>         Program exited normally.
>         (gdb) q
>         
>         
>          while on gentoo (amd64) i have a SIGABRT
>         
>         [easydbus.c at easydbus_deinit:64] Deinit EasyDbus 0.2 library...
>         process 22911: dbus_shutdown() called but connections were
>         still live. 
>         This probably means the application did not drop all its
>         references to
>         bus connections.
>         
>          /usr/lib/libdbus-1.so.3 [0x2ae4da416b5c]
>          /usr/lib/libdbus-1.so.3 [0x2ae4da4161e9]
>          /usr/lib/libdbus- 1.so.3 [0x2ae4da40c290]
>          /usr/lib/libdbus-1.so.3 [0x2ae4da3e44cb]
>          /usr/lib/libdbus-1.so.3(dbus_shutdown+0x21) [0x2ae4da40e881]
>          /home/geaaru/Projects/easydbus/sourceforge/easydbus/trunk/prefix//lib/libEasyDbus- 0.2.so(easydbus_deinit+0x3b) [0x2ae4da184584]
>          /mnt/crypt/Home_geaaru/Projects/easydbus/sourceforge/easydbus/trunk/test/.libs/list_services [0x400e67]
>          /lib/libc.so.6(__libc_start_main+0xf4) [0x2ae4da86eb74]
>          /mnt/crypt/Home_geaaru/Projects/easydbus/sourceforge/easydbus/trunk/test/.libs/list_services [0x400d19] 
>         
>         Program received signal SIGABRT, Aborted.
>         0x00002ae4da8815f5 in raise () from /lib/libc.so.6
>         
>         
>         On Wed, 2008-01-09 at 15:14 +0200, Naveen Verma wrote:
>         > Just I was also trying the same example as you mentioned
>         previously to 
>         > see the result. Of course in the case of session bus I did
>         not receive
>         > an error which I receive in the case of system bus. But
>         still it did
>         > not work properly because in dbus_shutdown() function the
>         program 
>         > exited with the exit status 1. So if i have anything after
>         > dbus_shutdown() function call that will never execute.
>         >
>         > Do you also finding the samilar result?
>         >
>         > -Br
>         > Naveen 
>         >
>         > On Jan 9, 2008 2:33 PM, Ge@@ru <geaaru at gmail.com> wrote:
>         >         Thanks at all for your replies.
>         >         Simon McVittie: in my application i use only libdbus
>         (through 
>         >         easydbus)
>         >         but i haven't other library that use it on my
>         process, my
>         >         problem is
>         >         handled still with simple example presented here.
>         Probably, as
>         >         said 
>         >         Peter Clifton is for a bug in DBus.
>         >
>         >         Ge@@ru
>         >
>         >
>         >
>         >         On Wed, 2008-01-09 at 12:24 +0000, Simon McVittie
>         wrote:
>         >         > On Wed, 09 Jan 2008 at 09:47:51 +0100, Ge@@ru
>         wrote: 
>         >         > > In this case on my application i do:
>         >         > > - dbus_bus_get (system bus)
>         >         > > - dbus_bus_request_name;
>         >         > > - ... do method call
>         >         > > - dbus_connection_unref() 
>         >         > > - dbus_shutdown
>         >         > > - exit
>         >         > >
>         >         > > On session bus this works fine, on system bus
>         >         > > before exit an abort is handled for: 
>         >         > >  dbus_shutdown() called but connections were
>         still live.
>         >         This probably
>         >         > > means the application did not drop all its
>         references to
>         >         bus
>         >         > > connections. 
>         >         > >
>         >         > > So, i can't shutdown on system bus.
>         >         >
>         >         > You're probably linked against a library that also
>         uses the
>         >         system bus. 
>         >         > In general you can't do that with shared
>         connections,
>         >         because you don't
>         >         > know who else will be using them.
>         >         >
>         >         > Don't call dbus_shutdown unless you know that your
>         code is 
>         >         the only user
>         >         > of libdbus in the process. You'll get a few
>         "memory leaks"
>         >         showing up in
>         >         > valgrind; work out which ones are libdbus
>         internals (thread 
>         >         locks and
>         >         > things like that) and ignore them.
>         >         >
>         >         > The documentation of dbus_shutdown also suggests
>         that it can
>         >         be useful
>         >         > if an application dlopens libdbus, but I don't
>         think its 
>         >         semantics are
>         >         > very useful in that case, since code that's
>         dlopened can't
>         >         (in general)
>         >         > know whether someone else has *also* dlopened
>         libdbus. I 
>         >         think the only
>         >         > solution for the dlopen case would be some sort of
>         >         dbus_library_ref and
>         >         > dbus_library_unref semantics (just like the way
>         dlopen and
>         >         dlclose are
>         >         > defined in terms of refcounting, in fact...)
>         >         > _______________________________________________
>         >         > dbus mailing list
>         >         > dbus at lists.freedesktop.org
>         >         > http://lists.freedesktop.org/mailman/listinfo/dbus
>         >
>         >         _______________________________________________ 
>         >         dbus mailing list
>         >         dbus at lists.freedesktop.org
>         >         http://lists.freedesktop.org/mailman/listinfo/dbus
>         >
>         >
>         
>         
> 



More information about the dbus mailing list