Menu
▾
▴
dbus-cplusplus-devel — Internal development and usage of the dbus-c++ API
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(22) |
Sep
(33) |
Oct
(1) |
Nov
(7) |
Dec
(19) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(12) |
Feb
(9) |
Mar
(11) |
Apr
(6) |
May
(3) |
Jun
(8) |
Jul
(9) |
Aug
(4) |
Sep
(12) |
Oct
(8) |
Nov
(9) |
Dec
(3) |
| 2010 |
Jan
(6) |
Feb
|
Mar
|
Apr
(4) |
May
(19) |
Jun
(5) |
Jul
(3) |
Aug
(6) |
Sep
(3) |
Oct
(4) |
Nov
|
Dec
(13) |
| 2011 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(18) |
Dec
(1) |
| 2012 |
Jan
(6) |
Feb
|
Mar
|
Apr
(1) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(3) |
Oct
(1) |
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
|
From: Martin G. <Mar...@as...> - 2017-12-04 15:24:02
|
Hi again! I just came across the following inconsistencies in the project's SourceForge main page <https://sourceforge.net/projects/dbus-cplusplus/>: * The license is given as being LGPL 2.0, but the COPYING file in the 0.9.0 tarball is LGPL 2.1. I assume that the latter are the current terms. * The "Source" link points to a non-existing gitorious path <https://gitorious.org/dbus-cplusplus>. * The "Tracker" and "Wiki" links on the website <http://dbus-cplusplus.sourceforge.net/index.html> point to non-existing pages, too. Regards Martin -- Mit freundlichen Grüssen Martin Gebert ____________________________________ Martin Gebert Softwareentwicklung AST-X GmbH Breitweidig 9 91301 Forchheim Tel. 09191-7362927-615 Fax. 09191 7362927-699 Mail Mar...@AS... AST-X GmbH Sitz der Gesellschaft: Forchheim Registergericht: Amtsgericht Bamberg, HRB 7943 Geschäftsführer: Helmut Leicht Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail sind nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden. |
|
From: Martin G. <Mar...@as...> - 2017-12-04 14:55:33
|
Hi!
I just started with incorporating libdbus-c++ into a Yocto based BSP in
order to use it with our applications. In the attached patch you'll find
two issues being addressed that I came across when cross-compiling:
1. Calling pipe() did fail due to a missing include of unistd.h.
2. The project specific includes were given as system paths. Admittedly
this is mainly a question of semantic correctness, as the build
worked with the unpatched source, too. I didn't check other source
files for this issue.
An additional issue has been that building with my custom Bitbake
recipe, and though the cross-compilation setup has been confirmed by the
configuration summary, the host compiler (g++) was used initially
instead of the cross compiler, which made linking fail (which in turn
was using the correct cross linker). I was able to force usage of the
correct compiler by explicitly setting the environment variable CXX
(plus CC, CPP and LD just to be sure) to the correct path. There may be
some inconsistency regarding cross-compilation support in the configure
script, so I thought you might be interested in this description. If
you want to investigate I can provide you the matching build logs and
generated makefiles.
Regards
Martin
--
Mit freundlichen Grüssen
Martin Gebert
____________________________________
Martin Gebert
Softwareentwicklung
AST-X GmbH
Breitweidig 9
91301 Forchheim
Tel. 09191-7362927-615
Fax. 09191 7362927-699
Mail Mar...@AS...
AST-X GmbH
Sitz der Gesellschaft: Forchheim
Registergericht: Amtsgericht Bamberg, HRB 7943
Geschäftsführer: Helmut Leicht
Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
Informationen. Wenn Sie nicht der richtige Adressat sind oder diese
E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den
Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren
sowie die unbefugte Weitergabe dieser E-Mail sind nicht gestattet.
This e-mail may contain confidential and/or privileged information.
If you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and destroy this e-mail.
Any unauthorised copying, disclosure or distribution of the material
in this e-mail is strictly forbidden.
|
|
From: Raghavendra. H. R <rag...@gm...> - 2017-08-31 09:19:37
|
Dear All,
I'm a newbie with dbus IPC mechanism.
I have one issue with dbus, looking forward for inputs which helps in
resolving my issue.
I'm running the dbus-daemon on a embedded device & getting the
"DBUS_SESSION_BUS_ADDRESS"
which I'm exporting on my shell.
Now running my executable *"dbus_bin"* which as code something like below
DBus::BusDispatcher dispatcher;
int main()
{
DBus::default_dispatcher = &dispatcher;
cout << "Before calling session BUS " << endl;
DBus::Connection bus = DBus::Connection::SessionBus();
cout << "Before calling request name " << endl;
bus.request_name("ib.si.notification");
cout << ": Starting the DBUS Server instance..." << endl;
dispatcher.enter();
}
When I run *"dbus_bin"* after getting the "DBUS_SESSION_BUS_ADDRESS" I can
see that my program is getting stuck at *"bus.request_name" *& doesn't
proceed.
I'm not able to make out the problem. Please help me regarding this issue.
--
Regards,
Raghavendra. H. R
(Raghu)
|
|
From: Kiran P. <kir...@gm...> - 2016-10-30 05:21:13
|
Hi, I am using dbus-c++ with glib eventloop integration. The examples provided with dbus-c++ always uses BusDispatcher as a global variable. I am using multi threaded application which uses dbus-c++ calls across threads. Currently in every thread I am locally creating creating a DBus::Glib::BusDispatcher variable( on stack ) and setting the default_dispatcher. The dispatcher will be destroyed as the thread completes. Is this advised ? The scenario I am worried about is two threads simulataneosuly creating DBus::Glib::BusDispatcher( as local variable) and setting default_dispatcher which affects the other thread. Is dbus-c++ expected to be used across threads ? Is default_dispatcher the only way to set a dispatcher ? An additional query: Is the sourceforge dbus-c++ repo maintained any more ? Thanks for reading, Kiran. |
|
From: Andreas V. <li...@br...> - 2016-09-24 09:28:28
|
Am Wed, 7 Sep 2016 09:43:23 -0400 schrieb John Simpson: Hello John, I don't like the debugging code in Dbus-C++. I took it over from the former maintainer. I have the long time plan to replace it with log4cxx when I've time -> what will never happen. :-P If you raise your arm to provide a patch to replace complete logging system with log4cxx than welcome :-) https://logging.apache.org/log4cxx/latest_stable/ regards Andreas > I have built libdbus-c++ with option --enable-debug > > The file debug.cpp contains the following line: > > static int debug_env = getenv("DBUSXX_VERBOSE") ? 1 : 0; > > However, adding some print statements to the code, I find that > getenv() is always returning null. > > For a sanity check, I added this line: > > system("echo DBUSXX_VERBOSE: $DBUSXX_VERBOSE > /dev/pts/1"); > > This prints out "DBUSXX_VERBOSE:" without a value, in spite of the > fact that I am launching with the variable set on the command line, > like this: > > # DBUSXX_VERBOSE=1 /bin/dbus-daemon --system --nofork > > So for some reason, it seems that the code is in a different > environment than that from which it was launched? > > I can get the debug output by commenting out the if structure, but I > would like to know why the environment isn't getting passed through, > and what is an appropriate procedure for enabling the debug messages. > > Package was built with dbus-c++_0.9.0.orig.tar.gz and > dbus-c++_0.9.0-6ubuntu1.debian.tar.gz > > System: > # uname -a > Linux SW0012 4.4.15-cec-release-rt23 #0 SMP PREEMPT RT Fri Aug 26 > 16:08:24 EDT 2016 i686 i686 i686 GNU/Linux > > # cat /etc/debian_version > jessie/sid > > # cat /etc/lsb-release > DISTRIB_ID=Ubuntu > DISTRIB_RELEASE=14.04 > DISTRIB_CODENAME=trusty > DISTRIB_DESCRIPTION="Ubuntu 14.04.4 LTS" > > # sed 8q config.log > This file contains any messages produced by compilers while > running configure, to aid debugging if configure makes a mistake. > > It was created by libdbus-c++ configure 0.9.0, which was > generated by GNU Autoconf 2.69. Invocation command line was > > $ ./configure --build=i686-linux-gnu --prefix=/usr > --includedir=${prefix}/include --mandir=${prefix}/share/man > --infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var > --libdir=${prefix}/lib/i386-linux-gnu > --libexecdir=${prefix}/lib/i386-linux-gnu --disable-maintainer-mode > --disable-dependency-tracking --enable-glib --disable-ecore > --enable-doxygen-docs --enable-debug > > Please let me know if any further info would be helpful. > > Thanks, > > > John -- Technical Blog <http://andreasvolz.wordpress.com/> |
|
From: Andreas V. <li...@br...> - 2016-09-24 09:23:30
|
Am Sat, 28 May 2016 13:21:40 -0700 schrieb yurivict: Merged - thanks! > > You can view, comment on, or merge this pull request online at: > > https://github.com/andreas-volz/dbus-cplusplus/pull/2 > > -- Commit Summary -- > > * Fixed undefined ssize_t for clang-3.8.0 on FreeBSD. > > -- File Changes -- > > M include/dbus-c++/pipe.h (2) > > -- Patch Links -- > > https://github.com/andreas-volz/dbus-cplusplus/pull/2.patch > https://github.com/andreas-volz/dbus-cplusplus/pull/2.diff > > --- > You are receiving this because you are subscribed to this thread. > Reply to this email directly or view it on GitHub: > https://github.com/andreas-volz/dbus-cplusplus/pull/2 -- Technical Blog <http://andreasvolz.wordpress.com/> |
|
From: John S. <joh...@sw...> - 2016-09-07 14:11:46
|
I have built libdbus-c++ with option --enable-debug
The file debug.cpp contains the following line:
static int debug_env = getenv("DBUSXX_VERBOSE") ? 1 : 0;
However, adding some print statements to the code, I find that getenv() is
always returning null.
For a sanity check, I added this line:
system("echo DBUSXX_VERBOSE: $DBUSXX_VERBOSE > /dev/pts/1");
This prints out "DBUSXX_VERBOSE:" without a value, in spite of the fact
that I am launching with the variable set on the command line, like this:
# DBUSXX_VERBOSE=1 /bin/dbus-daemon --system --nofork
So for some reason, it seems that the code is in a different environment
than that from which it was launched?
I can get the debug output by commenting out the if structure, but I would
like to know why the environment isn't getting passed through, and what is
an appropriate procedure for enabling the debug messages.
Package was built with dbus-c++_0.9.0.orig.tar.gz and
dbus-c++_0.9.0-6ubuntu1.debian.tar.gz
System:
# uname -a
Linux SW0012 4.4.15-cec-release-rt23 #0 SMP PREEMPT RT Fri Aug 26 16:08:24
EDT 2016 i686 i686 i686 GNU/Linux
# cat /etc/debian_version
jessie/sid
# cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=14.04
DISTRIB_CODENAME=trusty
DISTRIB_DESCRIPTION="Ubuntu 14.04.4 LTS"
# sed 8q config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by libdbus-c++ configure 0.9.0, which was
generated by GNU Autoconf 2.69. Invocation command line was
$ ./configure --build=i686-linux-gnu --prefix=/usr
--includedir=${prefix}/include --mandir=${prefix}/share/man
--infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
--libdir=${prefix}/lib/i386-linux-gnu
--libexecdir=${prefix}/lib/i386-linux-gnu --disable-maintainer-mode
--disable-dependency-tracking --enable-glib --disable-ecore
--enable-doxygen-docs --enable-debug
Please let me know if any further info would be helpful.
Thanks,
John
|
|
From: Olivier D. <oli...@gm...> - 2016-08-12 13:33:50
|
Hi guys, I need to create a small dbus server with one object and several interfaces, and I'm a bit stuck... My "Server" class inherits from the IntrospectableAdaptor, from the ObjectAdaptor and ONE adaptor generated by dbusxx-xml2cpp. Until here, everything is fine, but - Inheriting from two adaptors fails (amongst others because my adaptors have methods in common). - Having two separate "Server" classes, each one handling one interface fails when I give the same object name to both interfaces => I get two objects, and I need only one. Is there a solution for this ? Thank you, Olivier |
|
From: Andreas V. <li...@br...> - 2015-12-31 14:30:09
|
Hello all, There is a long silence on this list. I even didn't work much on DBus-C++ in the last years. It just worked fine for my application. :-) Now after one year inactivity I noticed that https://gitorious.org/ is down. Happily users have forked DBus-C++ to github. The new repository is: https://github.com/andreas-volz/dbus-cplusplus which is a fork of: https://github.com/pkgw/dbus-cplusplus and this is a fork of: https://github.com/Pelagicore/dbus-cplusplus which seems to be a fork of the 0.9 release. So nothing is lost. :-) I know there're several patches outside in the distribution. Also some are lost in the old Gitiorious. :-( Maybe we get them applied now on GitHub. regards Andreas -- Technical Blog <http://andreasvolz.wordpress.com/> |
|
From: Or G. <ob...@gm...> - 2015-04-18 12:25:24
|
Implementation of async code using latest c++11 threads |
|
From: Campbell H. <Cam...@ex...> - 2013-10-23 13:03:46
|
Hi, some advice required on how-to setup for exporting methods AND calling remote methods.
We have two modules, a network ping monitor (this application) and a PDU power monitor (remote).
Despite many variants on the theme, I cannot get this application to both advertise and utilize simultaneously.
We started with the example code from 'echo-server/-client' as a base, and can configure for client OR server successfully.
Of course, we have tried... A single DBus::Connection object; which, we thought should be OK and A non-thread version of the client code, that simply calls the required method on the client object?
The remote object is a python application using twisted, txdbus.
If this code is modified as server only, the remote can query this server OK, and if this is configured as client only then it can query the remote code OK.
// initialise our DBus connection
DBus::_init_threading();
DBus::default_dispatcher = &dispatcher;
// increase DBus-C++ frequency
new DBus::DefaultTimeout(100, false, &dispatcher);
// setup our DBus server
DBus::Connection serverconn = DBus::Connection::SystemBus();
serverconn.request_name(PINGD_SERVER_NAME);
pingdDBServer server(serverconn);
// setup our DBus client(s)
DBus::Connection powerclientconn = DBus::Connection::SystemBus();
powerProxy powerClient(powerclientconn,POWER_SERVER_PATH,POWER_SERVER_NAME);
g_client = &powerClient;
pthread_t threads[THREADS];
thread_pipe_list[0] = dispatcher.add_pipe(handler1, NULL);
pthread_create(&threads[0], NULL, greeter_thread, (void *)0);
pthread_join(threads[0], NULL);
// enter DBus event loop
dispatcher.enter();
printf("\ndispatcher run thread exited");
dispatcher.del_pipe(thread_pipe_list[0]);
I can of course supply other sections of code, to a point, but don't know where to start with that at this time so believe this is the crux of it!
Best regards
|
|
From: Leonel F. S. <leo...@cf...> - 2013-09-23 20:06:19
|
Hi friends: I need if you can to show me he a way to get register to a signal using libdbus-c++ an a way to set up a dbus object through network. -- |
|
From: Nicolas C. <nic...@gm...> - 2013-09-04 18:54:04
|
Hi, I noticed a certain discrepancy between the code generated by dbusxx-xml2cpp and the include directory used to install the libdbus-c++ library. Basically, dbusxx-xml2cpp generates classes that include <dbus-c++/dbus.h> while the install script places the includes in /usr/local/include/dbus-c++-1/dbus-c++. This means that compiling a project using a freshly generated proxy or adaptor from dbusxx-xml2cpp will fail. If you want to distribute a project that builds adaptors and proxys from xml files, it means you either have to post process generated header files to prepend dbus-c++-1 to the #include, or add dbus-c++-1 directory to the includes search path (which could be in /usr/local/include, as installed by the make install script, or /usr/include if installed through debian package or other package managers I suspect, or in the user's home directory if they have an include dir in their home on their search path and install with prefix). I currently "fixed" this by adding a symbolic link from /usr/include/dbus-c++ to /usr/include/dbus-c++-1/dbus-c++ (install directory on debian using the libdbus-c++-dev package), but that's not exactly clean. I suspect dbus-c++-1 is version to allow having multiple multiple versions of the library installed at the same time, but I'm not too sure (a few other files files in /usr/include seem to be versionnned, but not all that many). What would the implication of changing the default headers install directory to .../include/dbus-c++ be? If the above is impossible, should the include be changed to <dbus-c++-1/dbus-c++/dbus.h>? Thanks, -- Nicolas Calderon |
|
From: Andreas V. <li...@br...> - 2013-05-25 10:25:22
|
Am Thu, 23 May 2013 18:37:13 +0530 schrieb Keyur Patel: > Hi, > > > > I am using Dbus-C++ for C++ application for communication between Qt > application and C++ application. > > > > I need to create non-blocking object in C++ application. > > How to create it? Are you using XML file to generate your code? Then use NoReply annotation as shown here: http://sourceforge.net/apps/mediawiki/dbus-cplusplus/index.php?title=Introspection_Format Andreas -- Technical Blog <http://andreasvolz.wordpress.com/> |
|
From: Keyur P. <key...@ei...> - 2013-05-23 13:29:48
|
Hi, I am using Dbus-C++ for C++ application for communication between Qt application and C++ application. I need to create non-blocking object in C++ application. How to create it? Regards, Keyur Patel --------------------------------------------------------------------------------------------- Notice: This message has been scanned by Trend Micro Mail Security scanner and is believed to be clean --------------------------------------------------------------------------------------------- |
|
From: Matthieu C. <cha...@gm...> - 2012-05-24 20:53:49
|
Hi, I am currently working on using DBUS-c++ and I have an issue with signals. As you probably know, «mpris» is an unified interface to control mediaplayers. Consequently, several players can use it at the same time. My problem is: suppose that I want to control a mediaplayer, lets say Rhythmbox, which uses mpris, I need to catch every signal that it may send. however, lets say that Banshee is also running and is using mpris too. The problem is: my program (based on a basic implementation) catch signal from both Rhythmbox and Banshee. I had the Idea to filter with the sender identifier, included in the message. However, this value is written like this: «:1.343» while my sender filter would be «org.gnome.Rhythmbox3». What should I do? How can I filter the signal that I receive? Regards, Matthieu Charbonnier. |
|
From: Darrell S. <da...@sc...> - 2012-05-03 19:56:11
|
On Wed, May 2, 2012 at 10:53 PM, Darrell Schiebel <da...@sc...>wrote:
> a cleaner solution of adding it as an option to the XML to cpp converter
> (which generated the 'ViewerProxy.dbusproxy.h' header shown below).
This modification to support the specification of a timeout in xml2cpp like:
<method name="load" timeout="0x7fffffff/1000.0">
<arg direction="in" type="s" name="path" />
...
</method>
was straight forward to implement.
|
|
From: Darrell S. <da...@sc...> - 2012-05-03 02:54:47
|
I would like to be able to increase the timeout for method invocations. In the portion of the call stack shown below, timeout arguments are available at 'DBus::Connection::send_blocking( )' and below. Is there some way to do this that I have not discovered yet? Is providing the ability to set invocation timeout (in general or on a method by method basis) something that anyone has considered? It seems like there are a couple of possibilities. A gross solution like an environment variable or a cleaner solution of adding it as an option to the XML to cpp converter (which generated the 'ViewerProxy.dbusproxy.h' header shown below). Is this something that others would find useful? thanks for any comments, Darrell #0 0x000000010c328058 in dbus_connection_send_with_reply_and_block () #1 0x0000000107d57898 in DBus::Connection::send_blocking () #2 0x0000000107d503ac in DBus::ObjectProxy::_invoke_method () #3 0x0000000107d4c640 in DBus::InterfaceProxy::invoke_method () #4 0x0000000106baade1 in edu::nrao::casa::viewer_proxy::panel (this=0x113456960, type=@0x7fff5fbfa210, hidden=@0x7fff5fbf9b0c) at ViewerProxy.dbusproxy.h:205 #5 0x0000000106baaef9 in casa::ViewerProxy::panel (this=0x113456960, type=@0x7fff5fbfa210, hidden=false) at ViewerProxy.h:75 |
|
From: André P. <and...@ua...> - 2012-04-27 15:41:44
|
signal sender=:1.2529 -> dest=(null destination) serial=4 path=/fi/w1/wpa_supplicant1; interface=fi.w1.wpa_supplicant1; member=InterfaceAdded
object path "/fi/w1/wpa_supplicant1/Interfaces/1"
array [
dict entry(
string "Capabilities"
variant array [
dict entry(
string "Pairwise"
variant array [
string "ccmp"
string "tkip"
]
)
dict entry(
string "Group"
variant array [
string "ccmp"
string "tkip"
string "wep104"
string "wep40"
]
)
dict entry(
string "KeyMgmt"
variant array [
string "none"
string "ieee8021x"
string "wpa-eap"
string "wpa-psk"
string "wps"
]
)
dict entry(
string "Protocol"
variant array [
string "rsn"
string "wpa"
]
)
dict entry(
string "AuthAlg"
variant array [
string "open"
string "shared"
string "leap"
]
)
dict entry(
string "Scan"
variant array [
string "active"
string "passive"
string "ssid"
]
)
dict entry(
string "Modes"
variant array [
string "infrastructure"
string "ad-hoc"
]
)
]
)
dict entry(
string "State"
variant string "inactive"
)
dict entry(
string "Scanning"
variant boolean false
)
dict entry(
string "ApScan"
variant uint32 1
)
dict entry(
string "Ifname"
variant string "wlan0"
)
dict entry(
string "Driver"
variant string "wext"
)
dict entry(
string "BridgeIfname"
variant string ""
)
dict entry(
string "CurrentBSS"
variant object path "/"
)
dict entry(
string "CurrentNetwork"
variant object path "/"
)
dict entry(
string "Blobs"
variant array [
]
)
dict entry(
string "BSSs"
variant array [
]
)
dict entry(
string "Networks"
variant array [
]
)
] |
|
From: Saurav S. <Sau...@ha...> - 2012-01-26 20:25:13
|
Hi, I'm using dbus-c++ (the 6.15.2011 version) in a development project. This is a multi-threaded application, where the dispatcher is one thread, and there are other threads making d-bus client method calls. I didn't notice the pipe-based synchronization in the echo client example, so all of my worker threads currently call the dbus-c++ client methods directly. I have seen a few different deadlock scenarios in my application. All of them boil down to basically the same thing: * The dispatcher thread is holding _mutex_t and trying to handle an expired timeout * Either as part of handling the timeout, or from a different thread, libdbus is trying to add or remove another timeout * This reaches back up into dbus-c++ and tries to take the _mutex_t lock again This can happen all in the dispatcher thread, as this stack trace shows. This is a case where the dispatcher thread calls into libdbus, which comes back up to the dispatcher in the on_rem_timeout callback handler. This specific case might be handled by making _mutex_t recursive, but that won't solve the whole problem. #0 0x00007f5e176cd2f4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007f5e176c8d51 in _L_lock_110 () from /lib64/libpthread.so.0 #2 0x00007f5e176c8671 in __pthread_mutex_lock (mutex=0x591490) at pthread_mutex_lock.c:86 #3 0x00007f5e17cd4a15 in DBus::DefaultMutex::lock () from /lib64/libdbus-c++-1.so.0 #4 0x00007f5e17cd5f5c in DBus::DefaultTimeout::~DefaultTimeout () from /lib64/libdbus-c++-1.so.0 #5 0x00007f5e17cd8d61 in DBus::BusTimeout::~BusTimeout () from /lib64/libdbus-c++-1.so.0 #6 0x00007f5e17cd756b in DBus::BusDispatcher::rem_timeout () from /lib64/libdbus-c++-1.so.0 #7 0x00007f5e17ccfcd1 in DBus::Dispatcher::Private::on_rem_timeout () from /lib64/libdbus-c++-1.so.0 #8 0x00007f5e17e195de in _dbus_timeout_list_remove_timeout () from /lib64/libdbus-1.so.3 #9 0x00007f5e17dfbb90 in protected_change_timeout () from /lib64/libdbus-1.so.3 #10 0x00007f5e17dfbc2e in _dbus_connection_remove_timeout_unlocked () from /lib64/libdbus-1.so.3 #11 0x00007f5e17dfe958 in reply_handler_timeout () from /lib64/libdbus-1.so.3 #12 0x00007f5e17e196ea in dbus_timeout_handle () from /lib64/libdbus-1.so.3 #13 0x00007f5e17ccfe76 in DBus::Timeout::handle () from /lib64/libdbus-c++-1.so.0 #14 0x00007f5e17cd7752 in DBus::BusDispatcher::timeout_expired () from /lib64/libdbus-c++-1.so.0 #15 0x00007f5e17cd8ce3 in DBus::Callback<DBus::BusDispatcher, void, DBus::DefaultTimeout&>::call () from /lib64/libdbus-c++-1.so.0 #16 0x00007f5e17cd68c0 in DBus::Slot<void, DBus::DefaultTimeout&>::operator() () from /lib64/libdbus-c++-1.so.0 #17 0x00007f5e17cd4dbe in DBus::DefaultMainLoop::dispatch () from /lib64/libdbus-c++-1.so.0 #18 0x00007f5e17cd7866 in DBus::BusDispatcher::do_iteration () from /lib64/libdbus-c++-1.so.0 #19 0x00007f5e17cd7ad0 in DBus::BusDispatcher::enter () from /lib64/libdbus-c++-1.so.0 It can also happen across multiple threads, as the following stack traces show. In this case, the dispatcher holds _mutex_t inside dbus-c++, and is trying to get the connection lock inside libdbus. At the same time, a worker thread holds the connection lock inside libdbus, and is trying to get _mutex_t inside dbus-c++. Thread 78 (Thread 0x41a52950 (LWP 2451)): #0 0x00007f77f1e242f4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007f77f1e1fdbd in _L_lock_991 () from /lib64/libpthread.so.0 #2 0x00007f77f1e1fb6a in __pthread_mutex_lock (mutex=0x725350) at pthread_mutex_lock.c:69 #3 0x00007f77f257fc2a in _dbus_pthread_mutex_lock () from /lib64/libdbus-1.so.3 #4 0x00007f77f257087e in _dbus_mutex_lock () from /lib64/libdbus-1.so.3 #5 0x00007f77f2552718 in _dbus_connection_lock () from /lib64/libdbus-1.so.3 #6 0x00007f77f256ac48 in _dbus_pending_call_get_connection_and_lock () from /lib64/libdbus-1.so.3 #7 0x00007f77f2555932 in reply_handler_timeout () from /lib64/libdbus-1.so.3 #8 0x00007f77f25706ea in dbus_timeout_handle () from /lib64/libdbus-1.so.3 #9 0x00007f77f2427292 in DBus::Timeout::handle () from /lib64/libdbus-c++-1.so.0 #10 0x00007f77f242ecee in DBus::BusDispatcher::timeout_expired () from /lib64/libdbus-c++-1.so.0 #11 0x00007f77f243016f in DBus::Callback<DBus::BusDispatcher, void, DBus::DefaultTimeout&>::call () from /lib64/libdbus-c++-1.so.0 #12 0x00007f77f242de4a in DBus::Slot<void, DBus::DefaultTimeout&>::operator() () from /lib64/libdbus-c++-1.so.0 #13 0x00007f77f242c841 in DBus::DefaultMainLoop::dispatch () from /lib64/libdbus-c++-1.so.0 #14 0x00007f77f242ee62 in DBus::BusDispatcher::do_iteration () from /lib64/libdbus-c++-1.so.0 #15 0x00007f77f242f0cc in DBus::BusDispatcher::enter () from /lib64/libdbus-c++-1.so.0 Thread 60 (Thread 0x40c7f950 (LWP 3098)): #0 0x00007f77f1e242f4 in __lll_lock_wait () from /lib64/libpthread.so.0 #1 0x00007f77f1e1fd51 in _L_lock_110 () from /lib64/libpthread.so.0 #2 0x00007f77f1e1f671 in __pthread_mutex_lock (mutex=0x590490) at pthread_mutex_lock.c:86 #3 0x00007f77f242c0f9 in DBus::DefaultMutex::lock () from /lib64/libdbus-c++-1.so.0 #4 0x00007f77f242d8fc in DBus::DefaultTimeout::DefaultTimeout () from /lib64/libdbus-c++-1.so.0 #5 0x00007f77f242f93a in DBus::BusTimeout::BusTimeout () from /lib64/libdbus-c++-1.so.0 #6 0x00007f77f242f9ee in DBus::BusDispatcher::add_timeout () from /lib64/libdbus-c++-1.so.0 #7 0x00007f77f2426cc0 in DBus::Dispatcher::Private::on_add_timeout () from /lib64/libdbus-c++-1.so.0 #8 0x00007f77f257056f in _dbus_timeout_list_add_timeout () from /lib64/libdbus-1.so.3 #9 0x00007f77f2552b6b in protected_change_timeout () from /lib64/libdbus-1.so.3 #10 0x00007f77f2552bf7 in _dbus_connection_add_timeout_unlocked () from /lib64/libdbus-1.so.3 #11 0x00007f77f2552ca9 in _dbus_connection_attach_pending_call_unlocked () from /lib64/libdbus-1.so.3 #12 0x00007f77f2555bc1 in dbus_connection_send_with_reply () from /lib64/libdbus-1.so.3 #13 0x00007f77f2555e66 in dbus_connection_send_with_reply_and_block () from /lib64/libdbus-1.so.3 #14 0x00007f77f2422a03 in DBus::Connection::send_blocking () from /lib64/libdbus-c++-1.so.0 #15 0x00007f77f2418fed in DBus::ObjectProxy::_invoke_method () from /lib64/libdbus-c++-1.so.0 #16 0x00007f77f24139d6 in DBus::InterfaceProxy::invoke_method () from /lib64/libdbus-c++-1.so.0 I've spent several days on this, and haven't been able to figure out a solution. I can probably handle the case of adding a timeout by making the DefaultTimeout constructor put the timeout in a temporary list that's protected by a different lock, and then in the dispatch() function, copy those new timeouts over into the main _timeouts list. However, deleting a timeout becomes tricky, because libdbus frees the DbusTimeout structure after the callback returns. So if I defer the deletion in dbus-c++, or release the _mutex_t lock before processing the timeout, I run the risk of accessing freed memory. The only solution I've been able to come with is that the dispatcher thread needs to be synchronized with my worker threads. The echo-client example does this through the pipes, but switching my application to use pipes will require a major re-write of a lot of code. The other solution I can think of is to add a new Dispatcher::enter method that takes a mutex, use that to protect the whole dispatch loop, and ensure that all my worker threads use that same mutex when calling a client method. This way, only one thread is ever inside libdbus at any time. Of course, this isn't a very elegant solution, and it also results in fully serialized IPC, which isn't ideal. I thought I'd reach out to the list and see if anyone else had any advice to share. Maybe someone else has encountered this before? Maybe there's a patch for it in a branch somewhere that I haven't found? Or even if you just have some suggestions on how to try and address this, that would be most helpful. Thanks, Saurav |
|
From: Roy S. (RBEI/ECG1) <Roy...@in...> - 2012-01-09 05:28:03
|
Hi Andreas, Thank you for your response. :) As for your question : "Does this only happen with std::map or also with other types?" I've found that simple return types, that are of primitive types, like boolean, string, etc. work just fine. However, for maps, vectors it throws assertion errors. I have posted a bug on sf.net, as per your suggestion. (https://sourceforge.net/tracker/?func=detail&aid=3471247&group_id=236997&atid=1101682) I've marked it as a high priority bug, as it causes termination of process. Best Regards, Roy -----Original Message----- From: Andreas Volz [mailto:li...@br...] Sent: Saturday, January 07, 2012 4:25 AM To: dbu...@li... Subject: Re: [dbus-cplusplus-devel] Assertion error with MessageIter - arguments to dbus_message_iter_open_container() were incorrect Am Fri, 6 Jan 2012 12:38:56 +0800 schrieb Roy Samuel (RBEI/ECG1): > Hi, > > I am using the dbus-c++ binding to create a proxy for connman's > Service API which is exposed on dbus. The method found in connman's > Service interface xml, looks like so: > > <method name="GetProperties"> > <arg type="a{sv}" direction="out"/> > </method> > > The proxy file that was auto-generated using "dbusxx-xml2cpp" utility, > created the method in question like so: > > Line 1: std::map< std::string, ::DBus::Variant > > GetProperties() Line 2: { > Line 3: ::DBus::CallMessage call; > Line 4: call.member("GetProperties"); > Line 5: ::DBus::Message ret = invoke_method (call); > Line 6: ::DBus::MessageIter ri = ret.reader(); > Line 7: std::map< std::string, ::DBus::Variant > > argout; Line 8: ri >> argout; > Line 9: return argout; > Line 10: } > > > It's on Line 8, that I get the warning/error, > on x86 running Ubuntu 11.04 with libdbus-c++-1-0 > package(0~20110310-1ubuntu1): > > process 30342: arguments to dbus_message_iter_open_container() were > incorrect, assertion "(type == DBUS_TYPE_STRUCT && > contained_signature == NULL) || (type == DBUS_TYPE_DICT_ENTRY && > contained_signature == NULL) || (type == DBUS_TYPE_VARIANT && > contained_signature != NULL) || (type == DBUS_TYPE_ARRAY && > contained_signature != NULL)" failed in file dbus-message.c line > 2677. This is normally a bug in some application using the D-Bus > library. process 30342: dbus message iterator looks uninitialized or > corrupted > > ....and lots more..... But the process does not terminate/abort here. > > On meego however, running on an arm based target, > the process TERMINATES after this assertion error! > > The package used in meego on the arm based board is: > libdbus-c++-0.5.1-4.3.armv7hl.rpm > libdbus-c++-devel-0.5.1-4.3.armv7hl.rpm > > Please help in resolving this issue. > Is there another way in which the iterator can insert the DICT value > - (std::map< std::string, ::DBus::Variant > ) without throwing these > assertion errors? > > Any help woule be appreciated. Thank you very much for this report. I really don't use ofter "out" values in methods. So it couldn't say it's working for sure. I'll check this in near future and enhance unit tests for "out" values. Does this only happen with std::map or also with other types? Could you please create an trouble ticket in sf.net project as further reference about this? regards Andreas -- Technical Blog <http://andreasvolz.wordpress.com/> ------------------------------------------------------------------------------ Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox _______________________________________________ dbus-cplusplus-devel mailing list dbu...@li... https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel |
|
From: Andreas V. <li...@br...> - 2012-01-06 22:55:11
|
Am Fri, 6 Jan 2012 12:38:56 +0800 schrieb Roy Samuel (RBEI/ECG1):
> Hi,
>
> I am using the dbus-c++ binding to create a proxy for connman's
> Service API which is exposed on dbus. The method found in connman's
> Service interface xml, looks like so:
>
> <method name="GetProperties">
> <arg type="a{sv}" direction="out"/>
> </method>
>
> The proxy file that was auto-generated using "dbusxx-xml2cpp" utility,
> created the method in question like so:
>
> Line 1: std::map< std::string, ::DBus::Variant >
> GetProperties() Line 2: {
> Line 3: ::DBus::CallMessage call;
> Line 4: call.member("GetProperties");
> Line 5: ::DBus::Message ret = invoke_method (call);
> Line 6: ::DBus::MessageIter ri = ret.reader();
> Line 7: std::map< std::string, ::DBus::Variant >
> argout; Line 8: ri >> argout;
> Line 9: return argout;
> Line 10: }
>
>
> It's on Line 8, that I get the warning/error,
> on x86 running Ubuntu 11.04 with libdbus-c++-1-0
> package(0~20110310-1ubuntu1):
>
> process 30342: arguments to dbus_message_iter_open_container() were
> incorrect, assertion "(type == DBUS_TYPE_STRUCT &&
> contained_signature == NULL) || (type == DBUS_TYPE_DICT_ENTRY &&
> contained_signature == NULL) || (type == DBUS_TYPE_VARIANT &&
> contained_signature != NULL) || (type == DBUS_TYPE_ARRAY &&
> contained_signature != NULL)" failed in file dbus-message.c line
> 2677. This is normally a bug in some application using the D-Bus
> library. process 30342: dbus message iterator looks uninitialized or
> corrupted
>
> ....and lots more..... But the process does not terminate/abort here.
>
> On meego however, running on an arm based target,
> the process TERMINATES after this assertion error!
>
> The package used in meego on the arm based board is:
> libdbus-c++-0.5.1-4.3.armv7hl.rpm
> libdbus-c++-devel-0.5.1-4.3.armv7hl.rpm
>
> Please help in resolving this issue.
> Is there another way in which the iterator can insert the DICT value
> - (std::map< std::string, ::DBus::Variant > ) without throwing these
> assertion errors?
>
> Any help woule be appreciated.
Thank you very much for this report. I really don't use ofter "out"
values in methods. So it couldn't say it's working for sure. I'll check
this in near future and enhance unit tests for "out" values.
Does this only happen with std::map or also with other types?
Could you please create an trouble ticket in sf.net project as further
reference about this?
regards
Andreas
--
Technical Blog <http://andreasvolz.wordpress.com/>
|
|
From: Andreas V. <li...@br...> - 2012-01-06 22:50:11
|
Am Wed, 21 Dec 2011 21:19:56 +0200 schrieb Or Goshen: > Hi > > Is it possible to enter the async code into the master branch ? > Right now an adapter can only handle one call at a time and is > blocking other impending calls. > For anything that takes more than a split second this is a real > problem which can end with the client(s) getting a timeout. You could use NoReply annotation for methods: <annotation name="org.freedesktop.DBus.Method.NoReply" value="true"/> This is as if you use async call. You just have no async return value. You've to send a signal back if you need it. I always do this and name the back-signal with suffix "Result". This should work. But yes, async code as in glib handling would be nice. Do you know if someone else is working on it? I ask only because you sau "enter master branch" as if it's implemented in another branch. regards Andreas -- Technical Blog <http://andreasvolz.wordpress.com/> |
|
From: Roy S. (RBEI/ECG1) <Roy...@in...> - 2012-01-06 04:58:20
|
Hi,
I am using the dbus-c++ binding to create a proxy for connman's Service API which is exposed on dbus.
The method found in connman's Service interface xml, looks like so:
<method name="GetProperties">
<arg type="a{sv}" direction="out"/>
</method>
The proxy file that was auto-generated using "dbusxx-xml2cpp" utility,
created the method in question like so:
Line 1: std::map< std::string, ::DBus::Variant > GetProperties()
Line 2: {
Line 3: ::DBus::CallMessage call;
Line 4: call.member("GetProperties");
Line 5: ::DBus::Message ret = invoke_method (call);
Line 6: ::DBus::MessageIter ri = ret.reader();
Line 7: std::map< std::string, ::DBus::Variant > argout;
Line 8: ri >> argout;
Line 9: return argout;
Line 10: }
It's on Line 8, that I get the warning/error,
on x86 running Ubuntu 11.04 with libdbus-c++-1-0 package(0~20110310-1ubuntu1):
process 30342: arguments to dbus_message_iter_open_container() were incorrect, assertion "(type == DBUS_TYPE_STRUCT && contained_signature == NULL) || (type == DBUS_TYPE_DICT_ENTRY && contained_signature == NULL) || (type == DBUS_TYPE_VARIANT && contained_signature != NULL) || (type == DBUS_TYPE_ARRAY && contained_signature != NULL)" failed in file dbus-message.c line 2677.
This is normally a bug in some application using the D-Bus library.
process 30342: dbus message iterator looks uninitialized or corrupted
....and lots more..... But the process does not terminate/abort here.
On meego however, running on an arm based target,
the process TERMINATES after this assertion error!
The package used in meego on the arm based board is:
libdbus-c++-0.5.1-4.3.armv7hl.rpm
libdbus-c++-devel-0.5.1-4.3.armv7hl.rpm
Please help in resolving this issue.
Is there another way in which the iterator can insert the DICT value - (std::map< std::string, ::DBus::Variant > ) without throwing these assertion errors?
Any help woule be appreciated.
-Roy Samuel.
|
|
From: Andreas V. <li...@br...> - 2011-12-01 13:50:14
|
Hello together, This is the official release of DBus-C++ as version 0.9.0! Please download source and documentation from here: https://sourceforge.net/projects/dbus-cplusplus/files/dbus-c%2B%2B/0.9.0/ The new project website and documentation are available here: http://dbus-cplusplus.sourceforge.net/index.html Distribution packagers are welcome to build binary packages for DBus-C++. The DBus-C++ library is well tested with Ubuntu 10.04 and compile tested with Ubuntu 9.04. Please test DBus-C++ 0.9.0 and report bugs on SF.net to enable a bugfix release 0.9.x if needed. This is the bugfix branch for DBus-C++ 0.9 on gitorious: https://gitorious.org/dbus-cplusplus/mainline/commits/release-0.9 (commit 1f6f3e6 is 0.9.0) New features and bigger patches will be merged in the next major version 1.0.0. (gitorious: 'master') regards Andreas -- Technical Blog <http://andreasvolz.wordpress.com/> |
5 messages has been excluded from this view by a project administrator.
