Created attachment 51075 [details] In the attachment are dbus verbose logs first without the freeze and the second with freeze. We use DBus in several of our software. We are using libDbus++ 0.6.4 as DBus wrapper to our C++ software. Recently we saw our software freezing for 25 seconds (which is IMHO the default timeout for dbus_connection_send_with_reply_and_block). The freeze occurs on the Proxy/Client side when the server emits a DBus signal (the client has connected to) from inside a DBus method handler. After the freeze the program continues as expected. To reproduce the freeze we implemented a very simple DBUS Server and Proxy. The server offers one method (doSomethingAndSignal) and one signal (iDidSomething). The signal is emitted from inside the method. The proxy registers for the signal and invokes the method in a while loop. This example triggers the freeze in approx. 1 to 10 percent of the calls. If we set the timeout parameter of dbus_connection_send_with_reply_and_block (inside libDbus++) to DBUS_TIMEOUT_INFINITE the freeze does not occur. Also a "sleep" between the signaling and the return of the method handler prevents the freeze. In the attachment are dbus verbose logs first without the freeze and the second with freeze.
Can you include that simple example too? Note that the D-Bus API is not reentrant. If you recurse into the API, you might experience a deadlock condition.
Created attachment 51119 [details] Example Server/Client application to reproduce the described behavior.
(In reply to comment #1) > Can you include that simple example too? I have atached the example. > Note that the D-Bus API is not reentrant. If you recurse into the API, you > might experience a deadlock condition. Does this mean that I can not emit a signal from inside a dbus method handler?
You *can* send signals from inside method handlers. You just have to be really careful about which methods you're calling. I'm sorry, I can't read your code. I need it to be libdbus-1 only. I have no clue about the binding you're using. My best recommendation is that you don't send signals from inside callbacks from the library. Instead, break out of the library and send the signal from there. For example, post an event to yourself from the callback and handle it at the next event-loop iteration.
(In reply to comment #0) > We are using libDbus++ 0.6.4 libDbus++ isn't part of the core D-Bus library (libdbus-1); please contact the authors of libDbus++. This bug tracking system only deals with projects hosted on freedesktop.org, which includes the core D-Bus library, dbus-glib and dbus-python, but not (for instance) GDBus or dbus-c++. It's also not a C++ binding I've heard of: I've encountered QtDBus (part of Qt), dbus-cpp (unmaintained and deprecated), dbus-c++ (dbus-cplusplus on Sourceforge), and dbus-cxx (dbus-cxx on Sourceforge), but not libDbus++. If libDbus++ is a separate library, please list it on <http://www.freedesktop.org/wiki/Software/DBusBindings> or ask its authors to do so. It's entirely possible that there's some sort of deadlock in libdbus-1, particularly if threads are involved; but if there is, we'll need a test case that doesn't use an obscure binding.
(In reply to comment #5) > (In reply to comment #0) > > We are using libDbus++ 0.6.4 > > libDbus++ isn't part of the core D-Bus library (libdbus-1); please contact the > authors of libDbus++. This bug tracking system only deals with projects hosted > on freedesktop.org, which includes the core D-Bus library, dbus-glib and > dbus-python, but not (for instance) GDBus or dbus-c++. > > It's also not a C++ binding I've heard of: I've encountered QtDBus (part of > Qt), dbus-cpp (unmaintained and deprecated), dbus-c++ (dbus-cplusplus on > Sourceforge), and dbus-cxx (dbus-cxx on Sourceforge), but not libDbus++. If > libDbus++ is a separate library, please list it on > <http://www.freedesktop.org/wiki/Software/DBusBindings> or ask its authors to > do so. > > It's entirely possible that there's some sort of deadlock in libdbus-1, > particularly if threads are involved; but if there is, we'll need a test case > that doesn't use an obscure binding. The libDbus++ library is hosted as libdbuspp on Sourceforge. It meets our requirements best. Unfortunately it seems to be unmaintained, there was no reaction on patches that we have committed. Does it make sense to list an unmaintained lib in the wiki? I'm pretty sure the freeze will also happen without libDbus++. In the next days i will try to reproduce the freeze without using libDbus++. As I'm not realy familiar with pure libdbus-1 API, it may take some time.
Resolving this NOTOURBUG until/unless we have a test case not depending on an obscure and unmaintained C++ binding.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.