Request for help debugging DBusServer ... (Re: Question ad private DBUS server, how to ...

rony rony at wu.ac.at
Wed Aug 10 02:31:49 PDT 2011 

While testing/debugging a language binding for ooRexx I arrived at
testing DBusServer (dbus_server_listen(), etc.).

The current implementation employs "dbus_server_set_watch_functions()",
but not "dbus_set_timeout_functions()", because there seems to be no
need for it. (Using a server watch loop running on a separate thread
waiting for clients to connect.)

The test programs are directly derived from those that I used for
testing service and client objects on the session/system bus. There all
programs run correctly in the meantime, i.e. they do not abend, no
matter how many connections I let use the service object.

For testing the private server functionality these test programs get
adapted to use the given addresses on the service and client sides, and
everything looks fine.

Except for two things:

    * the "org.freedesktop.DBus.Local.Disconnected" signal does not
      occur, when clients go away (just saw that signal arrive once or
      twice so far, while testing for hours),

    * it seems that sometimes abends occur, where rarely a backtrace is
      given. One that I got starts out with:

      *** glibc detected *** /usr/bin/rexx: double free or corruption (fasttop): 0x0000000000da8980 ***
      ======= Backtrace: =========
      /lib/x86_64-linux-gnu/libc.so.6(+0x78a8f)[0x7f92a0eefa8f]
      /lib/x86_64-linux-gnu/libc.so.6(+0x7b1bb)[0x7f92a0ef21bb]
      /lib/x86_64-linux-gnu/libc.so.6(realloc+0xf9)[0x7f92a0ef3b19]
      /lib/x86_64-linux-gnu/libdbus-1.so.3(+0x28321)[0x7f929e7f1321]
      /lib/x86_64-linux-gnu/libdbus-1.so.3(+0x28a98)[0x7f929e7f1a98]
      /lib/x86_64-linux-gnu/libdbus-1.so.3(+0x14217)[0x7f929e7dd217]
      /lib/x86_64-linux-gnu/libdbus-1.so.3(+0x14c18)[0x7f929e7ddc18]
      /lib/x86_64-linux-gnu/libdbus-1.so.3(+0x14f46)[0x7f929e7ddf46]
      /lib/x86_64-linux-gnu/libdbus-1.so.3(+0x1295f)[0x7f929e7db95f]
      /lib/x86_64-linux-gnu/libdbus-1.so.3(+0x12e35)[0x7f929e7dbe35]
      /lib/x86_64-linux-gnu/libdbus-1.so.3(dbus_message_new_method_call+0xfc)[0x7f929e7e0a4c]
      /usr/lib/libdbusoorexx.so(DbusBusCallMessage_impl+0x5d0)[0x7f929ea1ed49]
      /usr/lib/libdbusoorexx.so(DbusBusCallMessage+0x93)[0x7f929ea1e75f]
      /usr/lib/ooRexx/librexx.so.4(_ZN20RexxNativeActivation3runEP10RexxMethodP16RexxNativeMethodP10RexxObjectP10RexxStringPS5_mR15ProtectedObject+0xce)[0x7f92a20d91ae]
      /usr/lib/ooRexx/librexx.so.4(_ZN10RexxMethod3runEP12RexxActivityP10RexxObjectP10RexxStringPS3_mR15ProtectedObject+0x71)[0x7f92a2098361]
      /usr/lib/ooRexx/librexx.so.4(_ZN10RexxObject22processProtectedMethodEP10RexxStringP10RexxMethodPPS_mR15ProtectedObject+0x7d)[0x7f92a20a3f4d]
      /usr/lib/ooRexx/librexx.so.4(_ZN21RexxExpressionMessage8evaluateEP14RexxActivationP19RexxExpressionStack+0x256)[0x7f92a20fed36]
      /usr/lib/ooRexx/librexx.so.4(_ZN21RexxInstructionReturn7executeEP14RexxActivationP19RexxExpressionStack+0x44)[0x7f92a210cd44]
      /usr/lib/ooRexx/librexx.so.4(_ZN14RexxActivation3runEP10RexxObjectP10RexxStringPS1_mP15RexxInstructionR15ProtectedObject+0x11c)[0x7f92a20d1c9c]
      /usr/lib/ooRexx/librexx.so.4(_ZN8RexxCode3runEP12RexxActivityP10RexxMethodP10RexxObjectP10RexxStringPS5_mR15ProtectedObject+0x73)[0x7f92a20d5363]
      /usr/lib/ooRexx/librexx.so.4(_ZN10RexxMethod3runEP12RexxActivityP10RexxObjectP10RexxStringPS3_mR15ProtectedObject+0x71)[0x7f92a2098361]

      ... cut ... 

      /usr/lib/ooRexx/librexx.so.4(_ZN8RexxCode3runEP12RexxActivityP10RexxMethodP10RexxObjectP10RexxStringPS5_mR15ProtectedObject+0x73)[0x7f92a20d5363]
      /usr/lib/ooRexx/librexx.so.4(_ZN10RexxMethod3runEP12RexxActivityP10RexxObjectP10RexxStringPS3_mR15ProtectedObject+0x71)[0x7f92a2098361]
      /usr/lib/ooRexx/librexx.so.4(_ZN10RexxObject11messageSendEP10RexxStringPPS_mR15ProtectedObject+0xd3)[0x7f92a20a47d3]
      /usr/lib/ooRexx/librexx.so.4(_ZN21RexxExpressionMessage8evaluateEP14RexxActivationP19RexxExpressionStack+0x256)[0x7f92a20fed36]
      /usr/lib/ooRexx/librexx.so.4(_ZN25RexxInstructionAssignment7executeEP14RexxActivationP19RexxExpressionStack+0xf8)[0x7f92a2102298]
      /usr/lib/ooRexx/librexx.so.4(_ZN14RexxActivation3runEP10RexxObjectP10RexxStringPS1_mP15RexxInstructionR15ProtectedObject+0x11c)[0x7f92a20d1c9c]
      /usr/lib/ooRexx/librexx.so.4(_ZN14RexxActivation8dispatchEv+0x5b)[0x7f92a20d2a4b]
      /usr/lib/ooRexx/librexx.so.4(_ZN12RexxActivity9runThreadEv+0x13e)[0x7f92a20f589e]
      /usr/lib/ooRexx/librexx.so.4(_Z9threadFncPv+0x9)[0x7f92a2123999]
      /lib/x86_64-linux-gnu/libpthread.so.0(+0x6d8c)[0x7f92a19b2d8c]
      /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f92a0f5d04d]
      ======= Memory map: ========
      00400000-00401000 r-xp 00000000 08:01 8398528                            /usr/bin/rexx
      00601000-00602000 rw-p 00001000 08:01 8398528                            /usr/bin/rexx
      00d8e000-00daf000 rw-p 00000000 00:00 0                                  [heap]
      7f9298000000-7f9298021000 rw-p 00000000 00:00 0 
      7f9298021000-7f929c000000 ---p 00000000 00:00 0 
      7f929e540000-7f929e541000 ---p 00000000 00:00 0 
      7f929e541000-7f929e5c1000 rw-p 00000000 00:00 0 
      7f929e5c1000-7f929e5c8000 r-xp 00000000 08:01 14421729                   /lib/x86_64-linux-gnu/librt-2.13.soAborted
      rony at rony-linux:/mnt/root_e/rony/dev/dbus20110602/tutorials-dbus/c-api/work/dbusoorexx/tests$ 
          

Now it is not clear where the root of such errors is, hence I would like
to make sure what happens here, especially relating to the remark in the
DBus documentation:

    *Todo: <http://dbus.freedesktop.org/doc/api/html/todo.html#_todo000047>*

        Thread safety hasn't been tested much for DBusServer
        <http://dbus.freedesktop.org/doc/api/html/structDBusServer.html>

        Need notification to apps of disconnection, may matter for some
        transports

cf.
<http://dbus.freedesktop.org/doc/api/html/group__DBusServer.html#details>.


[The language binding library, when loaded, does a
"dbus_threads_init_default()".]

---

As my skills in using gdb and setting up debug environments in general
are more than rusty (too many years have gone by), I would appreciate
any help, pointers which would help me locate the source of these abends
when using DBusServer. Hence fool-proof directions of setting up such an
environment would be highly appreciated!

[I am more than wary doing anything with the installed dbus on my own as
I already got my fingers badly burned two months ago, when I started out
with the dbus language binding project and changed a system
configuration with the effect, that I had to install Ubuntu from
scratch, as our Linux gurus where also not able to help get XWindows up
and running anymore. That was the reason why I started the initial
development in virtual machines, such that such bad side-effects would
not harm the real system. Of course, I learned afterwards that I made a
silly mistake and now I would know how to correct that error. But
debugging also dbus itself is terra incognita for me, so "once burned,
always shy" is currently restricting my will to experiment, besides time
restrictions which are more and more piling up. The hope is that dbus
developers in the know however, would know what to do to keep everything
within limits.]

Of course, it would be fantastic if anyone of the DBus developers who
has any insight to DBusServer would step forward (privately or via the
list) and help debug this. If it is a problem in DBusServer it might be
that it is not a big one, given that the system/session DBus servers
appear to be rock-solid; in addition it would be very important for long
running private servers to learn about disconnected clients, so it
should be the case that DBusServer reliably sends the respective
"Disconnected" signals.

Any takers, helpers, ideas ?

---rony


On 08.08.2011 21:02, rony wrote:
> Hi Havoc,
>
> thank you very much for your information!
>
> On 08.08.2011 02:58, Havoc Pennington wrote:
>   
>> On Sun, Aug 7, 2011 at 2:05 PM, rony <rony at wu.ac.at> wrote:
>>   
>>     
>>> When setting up a private DBUS server, it is possible to accept/get
>>> connections to clients.
>>>
>>> Is there a way to find out as a server, when a client went away?
>>>
>>> Or with other words: how could one determine the connection that got
>>> shut down at the client side (in order to close that connection on the
>>> server) while the server goes on waiting on new clients?
>>>     
>>>       
>> You should get a Disconnected message on the server side in this case.
>> (A disconnect looks the same on both client and server side, if I
>> remember correctly and nothing has changed.)
>>   
>>     
> In the past couple of hours I have tried to go after that.
>
> At one point (about two hours ago) I was surprised, because indeed I got
> a signal from "org.freedesktop.DBus.Local" (object path
> "/org/freedesktop/DBus/Local") and a member named "Disconnected"! Then I
> started to change the code to cater for the Disconnect signals (to
> inform the Rexx DBus server object about the client's disconnection),
> but ever since it did not appear anymore. Not really sure why, as to the
> best of my knowledge I have not done anything that could possibly impact
> DBus.
>
> To reassure you or anyone else: the language binding implementation has
> its own message loop for connections using
> "dbus_connection_read_write(conn,milliTimeout)" and dumping all received
> messages does not yield the "Disconnect" signal message! (This is on
> DBus 1.4.6, 64-bit Ubuntu.)
>
> [The implementation of the language binding has for each connection an
> own message loop running on its own thread, each employing
> dbus_connection_read_write(); in addition, if a private server is
> created in addition a watch-loop runs (for allowing clients to connect
> to the server instance) on its own thread as well.]
>
> So, I am really stumped and would be very greatful for any ideas, hints
> that could direct me where to look and what to go after! It would be
> very helpful to learn from DBus when a connection from a client to the
> server got disconnected.
>
> TIA,
>
> ---rony
>
> _______________________________________________
> 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/20110810/f5a01b03/attachment-0001.htm>

More information about the dbus mailing list