dbus_shutdown call

[Naveen Verma]

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
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/dbus/attachments/20080109/7c92f784/attachment.htm