dbus-cplusplus-devel — Internal development and usage of the dbus-c++ API

[dbus-cplusplus-devel] Problem with the DBus::MessageIter::operator>>( DBus::MessageIter & iter, DBus::Variant & val )

[asdfffdsa <n8...@gm...>]

Hello, I am new to dbus-c++.  I am very enthusiastic about this project (and
the dbus and hal projects).  I've installed dbus-c++ from the Archlinux User
Repository ( dbus-c++ 20090929-1 ).  I will be downloading the source over
night to further inspect the problem (my ISP has a very strict usage
policy).

I seem to be having a problem with the DBus::MessageIter::operator>>(
DBus::MessageIter & iter, DBus::Variant & val ) function ( declaration is in
types.h ).  I've used the "dbusxx-xml2cpp" binary to generate proxy pattern
classes.

*Here is my code:*
// halDeviceProxy is a variable of a dbusxx-xml2cpp-generated proxy class
for the "org.freedesktop.Hal.device" interface
::DBus::Variant variant = halDeviceProxy.GetProperty(
std::string(propertyName) );


*Here is the dbusxx-xml2cpp-generated proxy code:*
::DBus::Variant GetProperty(const std::string& key)
{
        ::DBus::CallMessage call;
        ::DBus::MessageIter wi = call.writer();
        wi << key;
        call.member("GetProperty");
        ::DBus::Message ret = invoke_method(call);
        ::DBus::MessageIter ri = ret.reader();

        ::DBus::Variant argout;
        ri >> argout;  *// this line causes an exception to be thrown*
        return argout;
}


*The "ri >> argout" call is causing the following error/exception:*
terminate called after throwing an instance of 'DBus::ErrorInvalidArgs'
  what():  variant type expected
Aborted


Naturally, "ri >> argout" is passing in a variant type, so I'm not sure what
the problem is.  The odd thing about this is that functions such as
GetAllProperties() work fine (which returns a
std::map<std::string,DBus::Variant>).

I will be looking over the source when I get a chance, but if anyone has any
ideas in the mean time, it would be very helpful.

Re: [dbus-cplusplus-devel] dbus_bus_request_name with bluez

[Andreas V. <li...@br...>]

Am Mon, 05 Oct 2009 23:08:36 -0400 schrieb Randell Jesup:

> >I'm developing the dbus-c++, but I think my problem is dbus specific.
> >So I ask here.
> >
> >This is what I do on the terminal:
> >
> >> dbus-send --system --type=method_call --print-reply
> >> --dest=org.bluez / org.bluez.Manager.DefaultAdapter
> >
> >method return sender=:1.43 -> dest=:1.81 reply_serial=2
> >   object path "/org/bluez/11832/hci0"
> >
> >This works well. So I tried the python code:
> >
> >bus = dbus.SystemBus()
> >
> >bluez = dbus.Interface(bus.get_object("org.bluez", "/"),
> >						"org.bluez.Manager")
> >
> >print "DefaultAdapter: " + bluez.DefaultAdapter ()
> >
> >This prints:
> >
> >DefaultAdapter: /org/bluez/11832/hci0
> >
> >Also working, so I tested it with dbus-c++ and I get this error:
> >
> >> ./bluephone 
> >terminate called after throwing an instance of 'DBus::Error'
> >  what():  Connection ":1.83" is not allowed to own the service
> > "org.bluez" due to security policies in the configuration file
> 
> You didn't give the code used with dbus-c++ - the error implies (end
> the rest of what you wrote) it's NOT (just) calling
> or.bluez.Manager.DefaultAdapter.  The error implies bluephone tried to
> register the name org.bluez, which your dbus-send and python tests
> didn't do.

Ah, you're right. I made a copy&paste error from my own server
example. :-(

If I simply omit the request_name() call then it works like expected :-)

regards
Andreas

Re: [dbus-cplusplus-devel] dbus_bus_request_name with bluez

[Randell J. <rj...@wg...>]

>I'm developing the dbus-c++, but I think my problem is dbus specific.
>So I ask here.
>
>This is what I do on the terminal:
>
>> dbus-send --system --type=method_call --print-reply --dest=org.bluez / org.bluez.Manager.DefaultAdapter
>
>method return sender=:1.43 -> dest=:1.81 reply_serial=2
>   object path "/org/bluez/11832/hci0"
>
>This works well. So I tried the python code:
>
>bus = dbus.SystemBus()
>
>bluez = dbus.Interface(bus.get_object("org.bluez", "/"),
>						"org.bluez.Manager")
>
>print "DefaultAdapter: " + bluez.DefaultAdapter ()
>
>This prints:
>
>DefaultAdapter: /org/bluez/11832/hci0
>
>Also working, so I tested it with dbus-c++ and I get this error:
>
>> ./bluephone 
>terminate called after throwing an instance of 'DBus::Error'
>  what():  Connection ":1.83" is not allowed to own the service "org.bluez" due 
>  to security policies in the configuration file

You didn't give the code used with dbus-c++ - the error implies (end the
rest of what you wrote) it's NOT (just) calling
or.bluez.Manager.DefaultAdapter.  The error implies bluephone tried to
register the name org.bluez, which your dbus-send and python tests
didn't do.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone)
rj...@wg...

[dbus-cplusplus-devel] dbus_bus_request_name with bluez

[Andreas V. <li...@br...>]

Hello,

I'm developing the dbus-c++, but I think my problem is dbus specific.
So I ask here.

This is what I do on the terminal:

> dbus-send --system --type=method_call --print-reply --dest=org.bluez / org.bluez.Manager.DefaultAdapter

method return sender=:1.43 -> dest=:1.81 reply_serial=2
   object path "/org/bluez/11832/hci0"

This works well. So I tried the python code:

bus = dbus.SystemBus()

bluez = dbus.Interface(bus.get_object("org.bluez", "/"),
						"org.bluez.Manager")

print "DefaultAdapter: " + bluez.DefaultAdapter ()

This prints:

DefaultAdapter: /org/bluez/11832/hci0

Also working, so I tested it with dbus-c++ and I get this error:

> ./bluephone 
terminate called after throwing an instance of 'DBus::Error'
  what():  Connection ":1.83" is not allowed to own the service "org.bluez" due 
  to security policies in the configuration file
Aborted

So I debugged into the library and see this C code:

void Connection::request_name(const char *name, int flags)
{
	InternalError e;

	debug_log("%s: registering bus name %s", unique_name(), name);

	int ret = dbus_bus_request_name(_pvt->conn, name, flags, e);

        if (ret == -1)
        {
	       if (e) throw Error(e);
        }

	if (name)
	{
		_pvt->names.push_back(name);
		std::string match = "destination='" + _pvt->names.back() + "'";
		add_match(match.c_str());
	}
}

Debugger says:

flags = 0
name = "org.bluez"
ret = -1

So it throws the Error in this case. If I comment out the Exception throw
than my example works without problems. This is really strange and gets me 
to some questions:

* Did I a mistake?

* Why is the dbus-send working?

* Why is the Python example working

* Why does DBus simply give my application access to the liked service
  only by ignoring the error handling? Isn't this a little insecure?

BTW: I just found out if I start my application as root it also works
with enabled exception handling. Have I found a security hole (at least
in dbus-python and dbus-send)?

bluez-4.12-0ubuntu5

regards
Andreas

Re: [dbus-cplusplus-devel] dbus-c++ problem

[Andreas V. <li...@br...>]

Am Thu, 24 Sep 2009 18:46:01 +0300 schrieb Murat Demirten:

Hello Murat,

I was not able to run your application, with the same error:

> ./wpa
Initialize
terminate called after throwing an instance of 'DBus::Error'
  what():  The name fi.epitest.hostap.WPASupplicant.Interface was not
provided by any .service files Aborted

The reason for my system is probably that I've this DBus service not
running. I use wicd, not sure if this conflicts in any way.

But I tried something else to verify DBus::Connection::SystemBus
working (I most use SessionBus). I took the dbus-browser example from
dbus-c++ sources and changes SessionBus to SystemBus in line 129. There
you could browse the systembus.

Maybe from reading and hacking this example you get your example
working.

regards
Andreas

> Hi Andreas,
> I learned new things about dbus and now I'm working a fork of ruby
> dbus bindings.
> 
> There was problems with some programs for example wpa_supplicant which
> doesn't provide introspection, source code also doesn't include any
> xml service definition files.
> 
> So, I can find the signal and method names form wpa_supplicant's
> source code and I can call them with ruby dbus bindings.
> 
> But, when I want to use it with dbus-c++ it gives me a dbus error
> like that: terminate called after throwing an instance of
> 'DBus::Error' what():  The name
> fi.epitest.hostap.WPASupplicant.Interface was not provided by
> any .service files
> 
> In this example, I'm calling wpa_supplicant's state method, which just
> returns a string like "COMPLETED", "SCANNING" etc.
> 
> I wrote a wpa.xml declaration file, and I'm sending a dummy code which
> compiles and shows the problem.
> Now wpa signals work properly (you can see that if you comment out
> line 19 of main.cpp)
> 
> but I cannot call simple state() method on that interface.
> 
> I'm sending whole source to you which includes test.rb file also
> (simple ruby implementation of wpa_supplicant's state() method)
> 
> So, I want to find what wrongs and if I could find the problem, my
> next job will be to write a good documentation about that :)
> 
> If you have any free time to look at this example, I'll be very glad.
> 
> Regards,
> 
> 2009/8/12 Andreas Volz <and...@tu...>
> 
> > Am Fri, 7 Aug 2009 18:05:56 +0300 schrieb Murat Demirten:
> >
> > Hello Murat,
> >
> > to be honest, I don't know much about the .service stuff in DBus. I
> > never used it. I think it starts a defined service provider binary.
> > Maybe read this:
> >
> >
> > http://dbus.freedesktop.org/doc/dbus-specification.html#message-bus-starting-services
> >
> > Are you trying to do something like this?
> >
> > regards
> > Andreas
> >
> > > Hi,
> > >
> > > I want to write both of you because I'm working on this problem in
> > > last 4 dayse maybe you can show correct way to me.
> > >
> > > I just want to use Avahi services from DBus and it seems ok for
> > > some scenarios. For example, I can make an
> > > org.freedesktop.Avahi.Server interface and call the
> > > ServiceBrowserNew() method on it.
> > >
> > > Then, it returns a DBus::Path object and after that I can make a
> > > new instance of ServiceBrowser object with this path (
> > > http://avahi.org/download/ServiceBrowser.introspect.xml)
> > > It triggers the correct signal functions, ItemNew and ItemRemove,
> > > it is ok..
> > >
> > > But, with the same flows I couldn't use the EntryGroup interface.
> > >
> > > Firstly, I take a new DBus::Path from Server interface with
> > > EntryGroupNew() method
> > > (http://avahi.org/download/Server.introspect.xml) After that I'm
> > > trying to create a new EntryGroup interface as before, and it
> > > seems ok. But when I call a method from this objects, it says
> > > "The name org.freedesktop.Avahi.EntryGroup was not provided by
> > > any .service files"
> > >
> > > I tried to debug c++ api a lot but couldn't find a solution. It
> > > is ok if I use the avahi C client api directly.
> > >
> > > So, I want to ask that if there is a known problem with dbus-c++
> > > api or between avahi dbus interface?
> > >
> > > Regards,
> >
> >
> > --
> > Technical Blog <http://andreasvolz.wordpress.com/>
> >
> 
> 
> 
> -- 
> Murat Demirten
> Genel Müdür
> YeniHayat Bilişim Teknolojileri A.Ş.
> http://www.yh.com.tr
> (212) 210 77 36 (PBX)

Re: [dbus-cplusplus-devel] leave() timeout

[Andreas V. <li...@br...>]

Am Fri, 17 Jul 2009 18:50:45 -0400 schrieb Pierre-Luc Bacon:

Hello,

Sorry that I react so late. Now I had some time to spend. But the patch
doesn't apply to FDO or gitorious branch any longer. Could you adopt it
to the mainline? Then I would apply it as it looks good so far after a
first review.

regards
Andreas

> This solution was implemented and a new patch was made:
> https://sourceforge.net/tracker/?func=detail&aid=2823377&group_id=236997&atid=1101684
> 
> On Tue, 2009-07-14 at 20:17 +0200, Redouane SOUM wrote:
> > I already submitted a patch for that but it was for an old version
> > of libdbus-c++.
> > 
> > The way to fix this issue is to add a file descriptor (a pipe) to
> > the file descriptors we poll (fds).
> > Then when we call leave() function we write in the pipe and it'll
> > unblock the poll call.
> > 
> > Regards.
> > 
> > 
> > 
> > -----Message d'origine-----
> > De : Pierre-Luc Bacon
> > [mailto:pie...@sa...] Envoyé : mardi 14
> > juillet 2009 17:01 À : dbu...@li...
> > Objet : [dbus-cplusplus-devel] leave() timeout
> > 
> > Calling leave() makes our application to wait for 10 sec. This can
> > be a problem as a user might want to restart the application during
> > that 10sec time frame. From eventloop.cpp, I see that:
> > 
> > int wait_min = 10000;
> > 158 
> > 159     DefaultTimeouts::iterator ti;
> > 160 
> > 161     _mutex_t.lock();
> > 162 
> > 163     for (ti = _timeouts.begin(); ti != _timeouts.end(); ++ti) {
> > 164         if ( (*ti)->enabled() && (*ti)->interval() < wait_min)
> > 165             wait_min = (*ti)->interval();
> > 166     }
> > 167 
> > 168     _mutex_t.unlock();
> > 169 
> > 170     poll (fds, nfd, wait_min);
> > 
> > >From what I get of this portion of code, it loops to find the
> > DefaultTimeout with the smallest time interval, then poll with that
> > value.
> > 
> > Is this meant to be used internally for dbus-c++ only or could we 
> > add_timeout(Timeout::Internal *) without fear of breaking the
> > eventloop mechanism ?
> > 
> > Since:
> >    
> >  while (_running) {
> >         do_iteration();
> >  }
> > 
> > in enter() (eventloop-integration.cpp) and:
> > 
> > void BusDispatcher::leave()
> > {
> >     _running = false;
> > }
> > 
> > wouldn't it be better to think of another way to leave the event
> > loop in a more instantaneous manner ?
> > 
> > Pierre-Luc Bacon, 
> > Savoir-Faire Linux
> > http://www.sflphone.org
> > 
> > 
> > ----------------------------------------------------------------------------
> > --
> > Enter the BlackBerry Developer Challenge  
> > This is your chance to win up to $100,000 in prizes! For a limited
> > time, vendors submitting new applications to BlackBerry App
> > World(TM) will have the opportunity to enter the BlackBerry
> > Developer Challenge. See full prize
> > 
> > details at: http://p.sf.net/sfu/Challenge
> > _______________________________________________
> > dbus-cplusplus-devel mailing list
> > dbu...@li...
> > https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
> > 
> > 
> > ------------------------------------------------------------------------------
> > Enter the BlackBerry Developer Challenge  
> > This is your chance to win up to $100,000 in prizes! For a limited
> > time, vendors submitting new applications to BlackBerry App
> > World(TM) will have the opportunity to enter the BlackBerry
> > Developer Challenge. See full prize details at:
> > http://p.sf.net/sfu/Challenge
> > _______________________________________________
> > dbus-cplusplus-devel mailing list
> > dbu...@li...
> > https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
> 
> 
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited
> time, vendors submitting new applications to BlackBerry App World(TM)
> will have the opportunity to enter the BlackBerry Developer
> Challenge. See full prize details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> dbus-cplusplus-devel mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel

[dbus-cplusplus-devel] API issue in request_name(), race condition?

[Randell J. <rj...@wg...>]

For some reason I'm not receiving email from the list, though I can send
to it...  Please CC me on any reply for now.

Andreas Volz writes:
>Hello Randell,
>
>there was a good reason not to do this. See
>http://dbus.freedesktop.org/doc/api/html/group__DBusBus.html#g4b4903adad0199119c9e49ad18e0cb25
>
>The return value is not a simple int value. It could be some of:
>
>http://dbus.freedesktop.org/doc/api/html/group__DBusShared.html#g3741b483711f0bf115cd39aa7aacd8d2
>
>So simply returning a int would in the next step mean to include some
>dbus headers. This destroys the PIMPL design of dbus-c++. So maybe a
>correct way would be to create a enum with all available states in dbus
>and then use a switch or some table to match the bus to dbus-c++ types.

Well, a few comments: you already allow people to pass in dbus.h #define
values via the undocumented "flags" parameter (one has to read the
source to figure out what values are valid there - DBUS_NAME_FLAG_*).
And "PIMPL" is about having private interfaces not be declared in your
public header files, and hiding implementation, so I don't see a strong
requirement there.  The whole point of dbus-c++ is to wrap dbus, so
exposing dbus enumerations (or our re-enumerations of them) doesn't
bother me.

Second: The underlying return type is 'int'; a change to libdbus (or
alternate implementation) could add return values, so the return should
be 'int', and if you want to avoid needing to include dbus.h you can
mirror those defines in dbus-c++.  If you try to force a conversion to
dbus-c++-specific types and not pass it through, you have to decide what
to do if you get a value you didn't expect:
DBUS_CPLUSPLUS_REQUEST_NAME_REPLY_WTF?  And what does doing all of that
buy you in reality?

Relevant defines:
#define 	DBUS_NAME_FLAG_ALLOW_REPLACEMENT   0x1
#define 	DBUS_NAME_FLAG_REPLACE_EXISTING   0x2
#define 	DBUS_NAME_FLAG_DO_NOT_QUEUE   0x4

#define 	DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER   1
#define 	DBUS_REQUEST_NAME_REPLY_IN_QUEUE   2
#define 	DBUS_REQUEST_NAME_REPLY_EXISTS   3
#define 	DBUS_REQUEST_NAME_REPLY_ALREADY_OWNER   4

Single-instance servers are a major use-case, and need to be supported
easily.  If you want, you could wrap some of the functionality to make
things simpler on the implementer, instead of having to do this:

    DBus::Connection conn = DBus::Connection::SessionBus();
    FooService server(conn);

    // Make sure we never get two instances running!
    try 
    {
        int result;
        if ((result = conn.request_name(FOO_SERVER_NAME,DBUS_NAME_FLAG_DO_NOT_QUEUE)) !=
            DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER)
        {
            syslog(LOG_ERR,"Request_name returned %d",result);
            ecore_shutdown();
            return 1;
        }
    }
    catch(DBus::Error &e) 
    {
        syslog(LOG_ERR,"Service name not available: %s",e.message());
        ecore_shutdown();
        return 1;
    }

Also, while I'm at it, there seems to be a race condition either in
dbus-c++ (or in base dbus protocol, which seems less likely):

The sequence above causes this dbus traffic:
--------------------------------------------
signal sender=org.freedesktop.DBus -> dest=(null destination) path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.22"
   string ""
   string ":1.22"
method call sender=:1.22 -> dest=org.freedesktop.DBus path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello
signal sender=org.freedesktop.DBus -> dest=(null destination) path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string "com.foo.FooService"
   string ""
   string ":1.22"
method call sender=:1.22 -> dest=org.freedesktop.DBus path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=RequestName
   string "com.foo.FooService"
   uint32 4
method call sender=:1.22 -> dest=org.freedesktop.DBus path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "destination='com.foo.FooService'"
--------------------------------------------

That's fine, except that if someone is watching NameOwnerChanged for a
new com.foo.FooService owner, if they send a method to FooService
immediately it occurs *before* the last AddMatch, and doesn't get
delivered to FooService for 25 seconds (when a retry apparently occurs
in dbus). If the watcher adds a short delay (and thus AddMatch has been
done), the method is delivered to FooService immediately.

I suspect that dbus-c++ should be adding the match earlier, not after
dbus_bus_request_name() returns.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone)
rj...@wg...

Re: [dbus-cplusplus-devel] Problem with waiting for a service to be available

[Randell J. <rj...@wg...>]

For any on the dbus-cplusplus list, you can look at the dbus archives to
see the earlier messages here.  Note that the example below assumes the
patch to the dbus-c++ git tree for request_name() return values I
emailed to the list a week ago, though I don't think I've seen it appear
yet...

>>Just to reiterate and verify I'm not (or dbus-c++ isn't) doing something
>>wrong:
>>
>>When I receive signal "NameOwnerChanged" for ServiceName, if I send a
>>method to ServiceName *immediately* will it arrive there reliably (and
>>quickly)?  I'm seeing a 15-30 second delay (seems like a retry within
>>the dbus daemon) from when I send the method and the recipient appears
>>to receive it.  I know it's not queuing within Qt since dbus-monitor
>>shows the init method being sent immediately.
>
>Ok, I've resolved the problem.  There is a bit of a hole if you're not
>careful - dbus doesn't really protect you from it, and while a binding
>can, I suspect many of the them don't (include dbus-c++).
>
>The problem is that dbus-bus_request_name() will notify listeners that
>you own the name, but until you've created handlers for objects under
>that name people won't be able to successfully send you messages (though
>in practice, it appears that they're retried before giving up (15-30
>seconds later), and so by then the handlers exist).  If they're just
>itching to send you a message, they can beat the creation of the server
>object(s).
>
>In order to avoid all timing holes, you'd need to internally initialize
>all objects your entity supports before requesting the name.  Most
>sample code in dbus wrappers doesn't do this: it requests the name, then
>instantiates the object.  (Or at least so it seemed looking around the net).

Copied from below:
>The alternative (haven't tried it yet) is to put "FooService server(conn);"
>right before the "try {}" section, and dispense with server.Ready().

Note: at least in dbus-c++, the above does NOT work.  Even with creating
the FooService server object before request_name(), the first method
from someone watching NameOwnerChanged is delayed by ~25 seconds.
If the watcher waits 1 second after NameOwnerChanged or waits for
Ready() (per the example below), then everything works fast.

In dbus-monitor with --profile, I see that when the delay happens, the
AddMatch submitted by dbus-c++ following successful request_name()
occurs after the "watching" process has tried to send a method.  Eg:

(cleaned up for easier viewing)
sig	1253738585	/org/freedesktop/DBus	org.freedesktop.DBus	NameOwnerChanged
mc	1253738585	:1.17	/org/freedesktop/DBus	org.freedesktop.DBus	RequestName
mc	1253738585	:1.16	/com/foo/FooService	com.foo.FooService	init
mc	1253738585	:1.17	/org/freedesktop/DBus	org.freedesktop.DBus	AddMatch
mc	1253738610	:1.16	/com/foo/FooService	com.foo.FooService	version

Note the 25-second delay (and FooService doesn't see "init()" until the
end of those 25 seconds), and AddMatch is after init().  Note that
AddMatch is for FooService:

method call sender=:1.17 -> dest=org.freedesktop.DBus path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "destination='com.foo.FooService'"

If I add a 1-second delay to the watcher, you get this:

sig	1253738755	/org/freedesktop/DBus	org.freedesktop.DBus	NameOwnerChanged
mc	1253738755	:1.19	/org/freedesktop/DBus	org.freedesktop.DBus	RequestName
mc	1253738755	:1.19	/org/freedesktop/DBus	org.freedesktop.DBus	AddMatch
mc	1253738756	:1.18	/com/foo/FooService	com.foo.FooService	init
mc	1253738757	:1.18	/com/foo/FooService	com.foo.FooService	version

Note that AddMatch happens first, and no 25-second delay.

This may well be a hole in dbus-c++, however it feels like it might be a
race condition in the protocol itself - i.e. is the AddMatch after
dbus_bus_request_name needed in order to receive methods for that path/name?

>The other way to deal with it is to add an application-level protocol on
>top of DBus, like a "Ready()" signal raised when your service is ready
>to handle all requests.  Ugly but simple.  Example:
>
>>This is the dbus-c++ code for aquiring the name (assumes a patch to
>>dbus-c++ I sent in a few days ago to get the return code from 
>>dbus_bus_request_name()):
>>
>>    DBus::Connection conn = DBus::Connection::SessionBus();
>>    // Make sure we never get two instances running!
>>    try 
>>    {
>>        int result;
>>        syslog(LOG_INFO,"requesting name");
>>        if ((result = conn.request_name(SERVER_NAME,DBUS_NAME_FLAG_DO_NOT_QUEUE)) !=
>>            DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER)
>>        {
>>            syslog(LOG_ERR,"Request_name returned %d",result);
>>            ecore_shutdown();
>>            return 1;
>>        }
>>    }
>>    catch(DBus::Error &e) 
>>    {
>>        syslog(LOG_ERR,"Error: Request name failure: %s",e.message());
>>        ecore_shutdown();
>>        return 1;
>>    }
>
>     FooService server(conn);
>     server.Ready(); // tell the world - avoids races on ownership of the name


-- 
Randell Jesup, Worldgate
rj...@wg...

Re: [dbus-cplusplus-devel] API issue in request_name()

[Andreas V. <li...@br...>]

Am Mon, 14 Sep 2009 15:59:46 -0400 schrieb Randell Jesup:

Hello Randell,

there was a good reason not to do this. See
http://dbus.freedesktop.org/doc/api/html/group__DBusBus.html#g4b4903adad0199119c9e49ad18e0cb25

The return value is not a simple int value. It could be some of:

http://dbus.freedesktop.org/doc/api/html/group__DBusShared.html#g3741b483711f0bf115cd39aa7aacd8d2

So simply returning a int would in the next step mean to include some
dbus headers. This destroys the PIMPL design of dbus-c++. So maybe a
correct way would be to create a enum with all available states in dbus
and then use a switch or some table to match the bus to dbus-c++ types.

Maybe someone else has a better idea, but that would be my way.

regards
	Andreas

> The request_name() API has an issue:
> 
> Currently it looks like this:
> void Connection::request_name(const char *name, int flags)
> {
> ...
> 	dbus_bus_request_name(_pvt->conn, name, flags,
> e);	//we deliberately don't check return value ...
> }
> 
> It explicitly ignores the return code from dbus_bus_request_name().
> It does pass the flags, such as DBUS_NAME_FLAG_DO_NOT_QUEUE,
> ..._REPLACE_EXISTING, etc
> 
> This is a problem, since if you get an (ignored) response such as
> DBUS_REQUEST_NAME_REPLY_EXISTS, you as the caller to request_name have
> no way to tell if you ended up owning the name.  This makes
> implementing a singleton object problematic.  I may also be missing
> something about how the API is supposed to work (perhaps related to
> the match set up...), but it's not obvious.
> 
> request_name() should export the result so the application can decide
> if it wants to take action.
> 
> // flags are normal dbus_bus_request_name flags, result is normal
> return int Connection::request_name(const char *name, int flags)
> {
> 	InternalError e;
>         int result;
> 
> 	debug_log("%s: registering bus name %s", unique_name(), name);
> 
> 	result = dbus_bus_request_name(_pvt->conn, name, flags, e);
> 
> 	if (e) throw Error(e);
> 
> //	this->remove_match("destination");
> 
> 	if (name)
> 	{
> 		_pvt->names.push_back(name);
> 		std::string match = "destination='" +
> _pvt->names.back() + "'"; add_match(match.c_str());
> 	}
> 
>         return result;
> }
> 
> 
> Patch to implement this and add some docs to request_name():
> 
> Index: include/dbus-c++/connection.h
> ===================================================================
> RCS
> file: /usr/cvs/arm-utils/modules/dbus-cpp/include/dbus-c++/connection.h,v
> retrieving revision 1.1.1.1 diff -u -r1.1.1.1 connection.h
> --- include/dbus-c++/connection.h	28 Aug 2009 22:18:07
> -0000	1.1.1.1 +++ include/dbus-c++/connection.h	14 Sep
> 2009 19:59:50 -0000 @@ -408,7 +408,19 @@
>  	 */
>  	PendingCall send_async( Message& msg, int timeout = -1);
>  
> -	void request_name( const char* name, int flags = 0 );
> +	/*!
> +	 * \brief Requests ownership of the given name.
> +	 *
> +	 * The returned result will be one of be one of the normal
> results of
> +         * dbus_bus_request_name(), such as
> DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER
> +	 * or DBUS_DBUS_REQUEST_NAME_REPLY_IN_QUEUE if successful.
> +         * See <dbus-1.0/dbus-shared.h>.  Errors are thrown.
> +	 * 
> +	 * \param name The name to register as the owner of
> +         * \param flags Flags such as DBUS_NAME_FLAG_REPLACE_EXISTING
> +	 * \throw Error
> +         */
> +	int request_name( const char* name, int flags = 0 );
>      
>      unsigned long sender_unix_uid(const char *sender);
>  
> Index: src/connection.cpp
> ===================================================================
> RCS file: /usr/cvs/arm-utils/modules/dbus-cpp/src/connection.cpp,v
> retrieving revision 1.1.1.1
> diff -u -r1.1.1.1 connection.cpp
> --- src/connection.cpp	28 Aug 2009 22:18:08 -0000
> 1.1.1.1 +++ src/connection.cpp	14 Sep 2009 19:59:50 -0000
> @@ -378,13 +378,15 @@
>  	return PendingCall(new PendingCall::Private(pending));
>  }
>  
> -void Connection::request_name(const char *name, int flags)
> +// flags are normal dbus_bus_request_name flags, result is normal
> return +int Connection::request_name(const char *name, int flags)
>  {
>  	InternalError e;
> +        int result;
>  
>  	debug_log("%s: registering bus name %s", unique_name(),
> name); 
> -	dbus_bus_request_name(_pvt->conn, name, flags,
> e);	//we deliberately don't check return value
> +	result = dbus_bus_request_name(_pvt->conn, name, flags, e);
>  
>  	if (e) throw Error(e);
>  
> @@ -396,6 +398,8 @@
>  		std::string match = "destination='" +
> _pvt->names.back() + "'"; add_match(match.c_str());
>  	}
> +
> +        return result;
>  }
>  
>  unsigned long Connection::sender_unix_uid(const char *sender)
> 
> -- 
> Randell Jesup, Worldgate (developers of the Ojo videophone)
> rj...@wg...
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day trial. Simplify your report design, integration and deployment
> - and focus on what you do best, core application coding. Discover
> what's new with Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> dbus-cplusplus-devel mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
> 

[dbus-cplusplus-devel] API issue in request_name()

[Randell J. <rj...@wg...>]

The request_name() API has an issue:

Currently it looks like this:
void Connection::request_name(const char *name, int flags)
{
...
	dbus_bus_request_name(_pvt->conn, name, flags, e);	//we deliberately don't check return value
...
}

It explicitly ignores the return code from dbus_bus_request_name().  It
does pass the flags, such as DBUS_NAME_FLAG_DO_NOT_QUEUE,
..._REPLACE_EXISTING, etc

This is a problem, since if you get an (ignored) response such as
DBUS_REQUEST_NAME_REPLY_EXISTS, you as the caller to request_name have
no way to tell if you ended up owning the name.  This makes implementing
a singleton object problematic.  I may also be missing something about
how the API is supposed to work (perhaps related to the match set
up...), but it's not obvious.

request_name() should export the result so the application can decide if
it wants to take action.

// flags are normal dbus_bus_request_name flags, result is normal return
int Connection::request_name(const char *name, int flags)
{
	InternalError e;
        int result;

	debug_log("%s: registering bus name %s", unique_name(), name);

	result = dbus_bus_request_name(_pvt->conn, name, flags, e);

	if (e) throw Error(e);

//	this->remove_match("destination");

	if (name)
	{
		_pvt->names.push_back(name);
		std::string match = "destination='" + _pvt->names.back() + "'";
		add_match(match.c_str());
	}

        return result;
}


Patch to implement this and add some docs to request_name():

Index: include/dbus-c++/connection.h
===================================================================
RCS file: /usr/cvs/arm-utils/modules/dbus-cpp/include/dbus-c++/connection.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 connection.h
--- include/dbus-c++/connection.h	28 Aug 2009 22:18:07 -0000	1.1.1.1
+++ include/dbus-c++/connection.h	14 Sep 2009 19:59:50 -0000
@@ -408,7 +408,19 @@
 	 */
 	PendingCall send_async( Message& msg, int timeout = -1);
 
-	void request_name( const char* name, int flags = 0 );
+	/*!
+	 * \brief Requests ownership of the given name.
+	 *
+	 * The returned result will be one of be one of the normal results of
+         * dbus_bus_request_name(), such as DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER
+	 * or DBUS_DBUS_REQUEST_NAME_REPLY_IN_QUEUE if successful.
+         * See <dbus-1.0/dbus-shared.h>.  Errors are thrown.
+	 * 
+	 * \param name The name to register as the owner of
+         * \param flags Flags such as DBUS_NAME_FLAG_REPLACE_EXISTING
+	 * \throw Error
+         */
+	int request_name( const char* name, int flags = 0 );
     
     unsigned long sender_unix_uid(const char *sender);
 
Index: src/connection.cpp
===================================================================
RCS file: /usr/cvs/arm-utils/modules/dbus-cpp/src/connection.cpp,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 connection.cpp
--- src/connection.cpp	28 Aug 2009 22:18:08 -0000	1.1.1.1
+++ src/connection.cpp	14 Sep 2009 19:59:50 -0000
@@ -378,13 +378,15 @@
 	return PendingCall(new PendingCall::Private(pending));
 }
 
-void Connection::request_name(const char *name, int flags)
+// flags are normal dbus_bus_request_name flags, result is normal return
+int Connection::request_name(const char *name, int flags)
 {
 	InternalError e;
+        int result;
 
 	debug_log("%s: registering bus name %s", unique_name(), name);
 
-	dbus_bus_request_name(_pvt->conn, name, flags, e);	//we deliberately don't check return value
+	result = dbus_bus_request_name(_pvt->conn, name, flags, e);
 
 	if (e) throw Error(e);
 
@@ -396,6 +398,8 @@
 		std::string match = "destination='" + _pvt->names.back() + "'";
 		add_match(match.c_str());
 	}
+
+        return result;
 }
 
 unsigned long Connection::sender_unix_uid(const char *sender)

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone)
rj...@wg...

Re: [dbus-cplusplus-devel] Calling DeviceKit methods

[Andreas V. <li...@br...>]

Am Thu, 10 Sep 2009 12:46:38 +0500 schrieb Zoltan Bencik:

Hello Zoltan,

If you progress with wx main loop integration please come back. I'm
interested to get this into the dbus-c++ source.

regards
Andreas

> Hello Andreas,
> 
> Yes, dbus-c++ main loop was causing this problem.
> I solved this issue by firing all dbus-c++ calls in separate thread
> and now everything works as it should.
> This is temporary solution, which I'll be later rewriting to wx event
> loops.
> 
> Thanks for your help.
> 
> 
> On Wed, Sep 9, 2009 at 11:32 PM, Andreas Volz <li...@br...>
> wrote:
> > Am Wed, 9 Sep 2009 11:14:57 +0500 schrieb Zoltan Bencik:
> >
> > Hello Zoltan,
> >
> > I think that I know the problem. You use the DBus::BusDispatcher
> > dispatcher Dbus-C++ own main loop. This is not very good tested and
> > many people have reported problems.
> >
> > I use the glib and ecore (Gitorious branch) main loop integration
> > with success. You need a main loop integration that fits to
> > wxWidgets. I'm sure nobody has tested this yet. Maybe it will work
> > because the wxGTK toolkit works together with the glib main loop
> > integration.
> >
> > But pay attention that then it works only with wxGtk, but not other
> > wxWidget backends.
> >
> > Look in the glib example hot to use it.
> >
> > regards
> >        Andreas
> >
> >> Hello Andreas,
> >>
> >> Thanks for your kind response.
> >>
> >> It seems like the GUI library(wxWidgets on Linux, wxGTK build) I'm
> >> using is causing some problems(not sure).
> >> Could you please tell me if my dbus-c++ usage is correct from the
> >> code listed below?
> >> Maybe I missed to register some callbacks, which I have to handle,
> >> or passing method  parameters incorrectly,
> >> or anything else.
> >> GUI library throws me an assert, which has to deal with even
> >> notifiers. I tried to use dbus-c++ in console application, and
> >> UnMount worked just fine.
> >>
> >> Here is the stack trace from Eclipse IDE, when I try to call
> >> invoke_method. I don't think it will be any helpful, since it's
> >> trace when GUI is about to die.
> >>
> >> Thread [1] (Suspended)
> >>       22 pthread_mutex_unlock()  0x00ab51a0
> >>       21 _dl_open()  0x008f69eb
> >>       20 do_dlopen()  0x00a22952
> >>       19 _dl_catch_error()  0x008f2806
> >>       18 __libc_dlopen_mode()  0x00a22b15
> >>       17 init()  0x009fb858
> >>       16 pthread_once()  0x00ab73f0
> >>       15 backtrace()  0x009fba45
> >>       14 wxStackWalker::SaveStack()
> >> /home/zoltan/Development/wx/src/unix/stackwalk.cpp:169 0x083edb79
> >>       13 wxGUIAppTraits::ShowAssertDialog()
> >> /home/zoltan/Development/wx/src/gtk/utilsgtk.cpp:379 0x08216dd8
> >>       12 ShowAssertDialog()
> >> /home/zoltan/Development/wx/src/common/appbase.cpp:836 0x08363cd0
> >>       11 wxAppConsole::OnAssertFailure()
> >> /home/zoltan/Development/wx/src/common/appbase.cpp:445 0x08364042
> >>       10 wxApp::OnAssertFailure()
> >> /home/zoltan/Development/wx/src/gtk/app.cpp:556 0x0820556f
> >>       9
> >> wxOnAssert() /home/zoltan/Development/wx/src/common/appbase.cpp:711
> >> 0x08363df7 8 wxEventLoop::~wxEventLoop()
> >> /home/zoltan/Development/wx/src/gtk/evtloop.cpp:64 0x0830fedf
> >>       7 wxEventLoopPtr::~wxEventLoopPtr()
> >> /home/zoltan/Development/wx/src/common/appcmn.cpp:74 0x0826f6d5
> >>       6 wxEventLoopTiedPtr::~wxEventLoopTiedPtr()
> >> /home/zoltan/Development/wx/src/common/appcmn.cpp:74 0x082705f1
> >>       5 wxAppBase::MainLoop()
> >> /home/zoltan/Development/wx/src/common/appcmn.cpp:312 0x0826fe7a
> >>       4 wxAppBase::OnRun()
> >> /home/zoltan/Development/wx/src/common/appcmn.cpp:367 0x0826f8b3
> >>       3
> >> wxEntry() /home/zoltan/Development/wx/src/common/init.cpp:460
> >> 0x08395273 2
> >> wxEntry() /home/zoltan/Development/wx/src/common/init.cpp:472
> >> 0x08395479 1
> >> main() /home/zoltan/Development/DBusCPPTest/src/main_app.cpp:42
> >> 0x0808438b
> >>
> >>
> >> Thanks.
> >> br,
> >> -zoltan.
> >>
> >> On Wed, Sep 9, 2009 at 1:35 AM, Andreas Volz<li...@br...>
> >> wrote:
> >> > Am Tue, 8 Sep 2009 18:34:11 +0500 schrieb Zoltan Bencik:
> >> >
> >> > Hello Zoltan,
> >> >
> >> > I suggest you should compile dbus-c++ with debug option
> >> > (--configure --enable-debug), your application with -O0 -ggdb
> >> > and run it in gdb.
> >> >
> >> > This would tell us all a lot of useful information.
> >> >
> >> > regards
> >> >        Andreas
> >> >
> >> >> Hello All,
> >> >>
> >> >> I'm trying to mount and unmount devices through dbus-c++
> >> >> binding, using DeviceKit.Disks.Device interface methods.
> >> >> While trying to unmount device, I get a 'SIGTRAP' signal.
> >> >> Can anybody show me what I'm doing wrong in this code?
> >> >>
> >> >> Thanks, any help is very appreciated.
> >> >>
> >> >>
> >> >> // Proxy implementation
> >> >> DisksDeviceProxy::DisksDeviceProxy(DBus::Connection &connection,
> >> >> const char *object_path)
> >> >> : DBus::InterfaceProxy("org.freedesktop.DeviceKit.Disks"),
> >> >>   DBus::ObjectProxy(connection, object_path,
> >> >> "org.freedesktop.DeviceKit.Disks.Device")
> >> >> {
> >> >> }
> >> >>
> >> >> // Mount device
> >> >> void DisksDeviceProxy::MountDevice(const char *fstype,
> >> >> std::vector<std::string> &options)
> >> >> {
> >> >>       ::DBus::CallMessage call;
> >> >>       ::DBus::MessageIter wi = call.writer();
> >> >>
> >> >>       wi << fstype;
> >> >>       wi << options;
> >> >>       call.member("FilesystemMount");
> >> >>       ::DBus::Message ret = invoke_method (call);
> >> >>       ::DBus::MessageIter ri = ret.reader();
> >> >> }
> >> >>
> >> >> // Unmount device
> >> >> void DisksDeviceProxy::UnMountDevice(std::vector<std::string>
> >> >> &options) {
> >> >>       ::DBus::CallMessage call;
> >> >>       ::DBus::MessageIter wi = call.writer();
> >> >>
> >> >>       wi << options;
> >> >>       call.member("FilesystemUnmount");
> >> >>       ::DBus::Message ret = invoke_method (call); // Signaled
> >> >> SIGTRAP right here ::DBus::MessageIter ri = ret.reader();
> >> >> }
> >> >>
> >> >> And here is the code, how I'm trying to unmount device:
> >> >> //-- START
> >> >> DBus::BusDispatcher dispatcher;
> >> >> DBus::default_dispatcher = &dispatcher;
> >> >>
> >> >> DBus::Connection conn = DBus::Connection::SystemBus();
> >> >>
> >> >> DisksDeviceProxy devkit(conn,
> >> >> "/org/freedesktop/DeviceKit/Disks/devices/sdb1"); // for now,
> >> >> just hard coded value of my USB device
> >> >> std::vector<std::string>options;
> >> >> devkit.UnMountDevice(options);
> >> >> //-- END
> >> >>
> >> >> ------------------------------------------------------------------------------
> >> >> Let Crystal Reports handle the reporting - Free Crystal Reports
> >> >> 2008 30-Day trial. Simplify your report design, integration and
> >> >> deployment
> >> >> - and focus on what you do best, core application coding.
> >> >> Discover what's new with Crystal Reports now.
> >> >>  http://p.sf.net/sfu/bobj-july
> >> >> _______________________________________________
> >> >> dbus-cplusplus-devel mailing list
> >> >> dbu...@li...
> >> >> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
> >> >>
> >> >
> >> > ------------------------------------------------------------------------------
> >> > Let Crystal Reports handle the reporting - Free Crystal Reports
> >> > 2008 30-Day trial. Simplify your report design, integration and
> >> > deployment - and focus on what you do best, core application
> >> > coding. Discover what's new with Crystal Reports now.
> >> >  http://p.sf.net/sfu/bobj-july
> >> > _______________________________________________
> >> > dbus-cplusplus-devel mailing list
> >> > dbu...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
> >> >
> >>
> >
> > ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports
> > 2008 30-Day trial. Simplify your report design, integration and
> > deployment - and focus on what you do best, core application
> > coding. Discover what's new with Crystal Reports now.
> >  http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > dbus-cplusplus-devel mailing list
> > dbu...@li...
> > https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
> >
> 
> 
> 
> -- 
> Best regards,
> -zoltan.
> 

Re: [dbus-cplusplus-devel] Calling DeviceKit methods

[Zoltan B. <zol...@gm...>]

Hello Andreas,

Yes, dbus-c++ main loop was causing this problem.
I solved this issue by firing all dbus-c++ calls in separate thread
and now everything works as it should.
This is temporary solution, which I'll be later rewriting to wx event loops.

Thanks for your help.


On Wed, Sep 9, 2009 at 11:32 PM, Andreas Volz <li...@br...> wrote:
> Am Wed, 9 Sep 2009 11:14:57 +0500 schrieb Zoltan Bencik:
>
> Hello Zoltan,
>
> I think that I know the problem. You use the DBus::BusDispatcher
> dispatcher Dbus-C++ own main loop. This is not very good tested and
> many people have reported problems.
>
> I use the glib and ecore (Gitorious branch) main loop integration with
> success. You need a main loop integration that fits to wxWidgets. I'm
> sure nobody has tested this yet. Maybe it will work because the wxGTK
> toolkit works together with the glib main loop integration.
>
> But pay attention that then it works only with wxGtk, but not other
> wxWidget backends.
>
> Look in the glib example hot to use it.
>
> regards
>        Andreas
>
>> Hello Andreas,
>>
>> Thanks for your kind response.
>>
>> It seems like the GUI library(wxWidgets on Linux, wxGTK build) I'm
>> using is causing some problems(not sure).
>> Could you please tell me if my dbus-c++ usage is correct from the code
>> listed below?
>> Maybe I missed to register some callbacks, which I have to handle, or
>> passing method  parameters incorrectly,
>> or anything else.
>> GUI library throws me an assert, which has to deal with even
>> notifiers. I tried to use dbus-c++ in console application, and
>> UnMount worked just fine.
>>
>> Here is the stack trace from Eclipse IDE, when I try to call
>> invoke_method. I don't think it will be any helpful, since it's trace
>> when GUI is about to die.
>>
>> Thread [1] (Suspended)
>>       22 pthread_mutex_unlock()  0x00ab51a0
>>       21 _dl_open()  0x008f69eb
>>       20 do_dlopen()  0x00a22952
>>       19 _dl_catch_error()  0x008f2806
>>       18 __libc_dlopen_mode()  0x00a22b15
>>       17 init()  0x009fb858
>>       16 pthread_once()  0x00ab73f0
>>       15 backtrace()  0x009fba45
>>       14 wxStackWalker::SaveStack()
>> /home/zoltan/Development/wx/src/unix/stackwalk.cpp:169 0x083edb79
>>       13 wxGUIAppTraits::ShowAssertDialog()
>> /home/zoltan/Development/wx/src/gtk/utilsgtk.cpp:379 0x08216dd8
>>       12 ShowAssertDialog()
>> /home/zoltan/Development/wx/src/common/appbase.cpp:836 0x08363cd0
>>       11 wxAppConsole::OnAssertFailure()
>> /home/zoltan/Development/wx/src/common/appbase.cpp:445 0x08364042
>>       10 wxApp::OnAssertFailure()
>> /home/zoltan/Development/wx/src/gtk/app.cpp:556 0x0820556f
>>       9
>> wxOnAssert() /home/zoltan/Development/wx/src/common/appbase.cpp:711
>> 0x08363df7 8 wxEventLoop::~wxEventLoop()
>> /home/zoltan/Development/wx/src/gtk/evtloop.cpp:64 0x0830fedf
>>       7 wxEventLoopPtr::~wxEventLoopPtr()
>> /home/zoltan/Development/wx/src/common/appcmn.cpp:74 0x0826f6d5
>>       6 wxEventLoopTiedPtr::~wxEventLoopTiedPtr()
>> /home/zoltan/Development/wx/src/common/appcmn.cpp:74 0x082705f1
>>       5 wxAppBase::MainLoop()
>> /home/zoltan/Development/wx/src/common/appcmn.cpp:312 0x0826fe7a
>>       4 wxAppBase::OnRun()
>> /home/zoltan/Development/wx/src/common/appcmn.cpp:367 0x0826f8b3
>>       3
>> wxEntry() /home/zoltan/Development/wx/src/common/init.cpp:460
>> 0x08395273 2
>> wxEntry() /home/zoltan/Development/wx/src/common/init.cpp:472
>> 0x08395479 1
>> main() /home/zoltan/Development/DBusCPPTest/src/main_app.cpp:42
>> 0x0808438b
>>
>>
>> Thanks.
>> br,
>> -zoltan.
>>
>> On Wed, Sep 9, 2009 at 1:35 AM, Andreas Volz<li...@br...>
>> wrote:
>> > Am Tue, 8 Sep 2009 18:34:11 +0500 schrieb Zoltan Bencik:
>> >
>> > Hello Zoltan,
>> >
>> > I suggest you should compile dbus-c++ with debug option (--configure
>> > --enable-debug), your application with -O0 -ggdb and run it in gdb.
>> >
>> > This would tell us all a lot of useful information.
>> >
>> > regards
>> >        Andreas
>> >
>> >> Hello All,
>> >>
>> >> I'm trying to mount and unmount devices through dbus-c++ binding,
>> >> using DeviceKit.Disks.Device interface methods.
>> >> While trying to unmount device, I get a 'SIGTRAP' signal.
>> >> Can anybody show me what I'm doing wrong in this code?
>> >>
>> >> Thanks, any help is very appreciated.
>> >>
>> >>
>> >> // Proxy implementation
>> >> DisksDeviceProxy::DisksDeviceProxy(DBus::Connection &connection,
>> >> const char *object_path)
>> >> : DBus::InterfaceProxy("org.freedesktop.DeviceKit.Disks"),
>> >>   DBus::ObjectProxy(connection, object_path,
>> >> "org.freedesktop.DeviceKit.Disks.Device")
>> >> {
>> >> }
>> >>
>> >> // Mount device
>> >> void DisksDeviceProxy::MountDevice(const char *fstype,
>> >> std::vector<std::string> &options)
>> >> {
>> >>       ::DBus::CallMessage call;
>> >>       ::DBus::MessageIter wi = call.writer();
>> >>
>> >>       wi << fstype;
>> >>       wi << options;
>> >>       call.member("FilesystemMount");
>> >>       ::DBus::Message ret = invoke_method (call);
>> >>       ::DBus::MessageIter ri = ret.reader();
>> >> }
>> >>
>> >> // Unmount device
>> >> void DisksDeviceProxy::UnMountDevice(std::vector<std::string>
>> >> &options) {
>> >>       ::DBus::CallMessage call;
>> >>       ::DBus::MessageIter wi = call.writer();
>> >>
>> >>       wi << options;
>> >>       call.member("FilesystemUnmount");
>> >>       ::DBus::Message ret = invoke_method (call); // Signaled
>> >> SIGTRAP right here ::DBus::MessageIter ri = ret.reader();
>> >> }
>> >>
>> >> And here is the code, how I'm trying to unmount device:
>> >> //-- START
>> >> DBus::BusDispatcher dispatcher;
>> >> DBus::default_dispatcher = &dispatcher;
>> >>
>> >> DBus::Connection conn = DBus::Connection::SystemBus();
>> >>
>> >> DisksDeviceProxy devkit(conn,
>> >> "/org/freedesktop/DeviceKit/Disks/devices/sdb1"); // for now, just
>> >> hard coded value of my USB device
>> >> std::vector<std::string>options;
>> >> devkit.UnMountDevice(options);
>> >> //-- END
>> >>
>> >> ------------------------------------------------------------------------------
>> >> Let Crystal Reports handle the reporting - Free Crystal Reports
>> >> 2008 30-Day trial. Simplify your report design, integration and
>> >> deployment
>> >> - and focus on what you do best, core application coding. Discover
>> >> what's new with Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> >> _______________________________________________
>> >> dbus-cplusplus-devel mailing list
>> >> dbu...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
>> >>
>> >
>> > ------------------------------------------------------------------------------
>> > Let Crystal Reports handle the reporting - Free Crystal Reports
>> > 2008 30-Day trial. Simplify your report design, integration and
>> > deployment - and focus on what you do best, core application
>> > coding. Discover what's new with Crystal Reports now.
>> >  http://p.sf.net/sfu/bobj-july
>> > _______________________________________________
>> > dbus-cplusplus-devel mailing list
>> > dbu...@li...
>> > https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
>> >
>>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> dbus-cplusplus-devel mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
>



-- 
Best regards,
-zoltan.

Re: [dbus-cplusplus-devel] Calling DeviceKit methods

[Andreas V. <li...@br...>]

Am Wed, 9 Sep 2009 11:14:57 +0500 schrieb Zoltan Bencik:

Hello Zoltan,

I think that I know the problem. You use the DBus::BusDispatcher
dispatcher Dbus-C++ own main loop. This is not very good tested and
many people have reported problems.

I use the glib and ecore (Gitorious branch) main loop integration with
success. You need a main loop integration that fits to wxWidgets. I'm
sure nobody has tested this yet. Maybe it will work because the wxGTK
toolkit works together with the glib main loop integration.

But pay attention that then it works only with wxGtk, but not other
wxWidget backends.

Look in the glib example hot to use it.

regards
	Andreas

> Hello Andreas,
> 
> Thanks for your kind response.
> 
> It seems like the GUI library(wxWidgets on Linux, wxGTK build) I'm
> using is causing some problems(not sure).
> Could you please tell me if my dbus-c++ usage is correct from the code
> listed below?
> Maybe I missed to register some callbacks, which I have to handle, or
> passing method  parameters incorrectly,
> or anything else.
> GUI library throws me an assert, which has to deal with even
> notifiers. I tried to use dbus-c++ in console application, and
> UnMount worked just fine.
> 
> Here is the stack trace from Eclipse IDE, when I try to call
> invoke_method. I don't think it will be any helpful, since it's trace
> when GUI is about to die.
> 
> Thread [1] (Suspended)	
> 	22 pthread_mutex_unlock()  0x00ab51a0	
> 	21 _dl_open()  0x008f69eb	
> 	20 do_dlopen()  0x00a22952	
> 	19 _dl_catch_error()  0x008f2806	
> 	18 __libc_dlopen_mode()  0x00a22b15	
> 	17 init()  0x009fb858	
> 	16 pthread_once()  0x00ab73f0	
> 	15 backtrace()  0x009fba45	
> 	14 wxStackWalker::SaveStack()
> /home/zoltan/Development/wx/src/unix/stackwalk.cpp:169 0x083edb79
> 	13 wxGUIAppTraits::ShowAssertDialog()
> /home/zoltan/Development/wx/src/gtk/utilsgtk.cpp:379 0x08216dd8
> 	12 ShowAssertDialog()
> /home/zoltan/Development/wx/src/common/appbase.cpp:836 0x08363cd0
> 	11 wxAppConsole::OnAssertFailure()
> /home/zoltan/Development/wx/src/common/appbase.cpp:445 0x08364042
> 	10 wxApp::OnAssertFailure()
> /home/zoltan/Development/wx/src/gtk/app.cpp:556 0x0820556f
> 	9
> wxOnAssert() /home/zoltan/Development/wx/src/common/appbase.cpp:711
> 0x08363df7 8 wxEventLoop::~wxEventLoop()
> /home/zoltan/Development/wx/src/gtk/evtloop.cpp:64 0x0830fedf
> 	7 wxEventLoopPtr::~wxEventLoopPtr()
> /home/zoltan/Development/wx/src/common/appcmn.cpp:74 0x0826f6d5
> 	6 wxEventLoopTiedPtr::~wxEventLoopTiedPtr()
> /home/zoltan/Development/wx/src/common/appcmn.cpp:74 0x082705f1
> 	5 wxAppBase::MainLoop()
> /home/zoltan/Development/wx/src/common/appcmn.cpp:312 0x0826fe7a
> 	4 wxAppBase::OnRun()
> /home/zoltan/Development/wx/src/common/appcmn.cpp:367 0x0826f8b3
> 	3
> wxEntry() /home/zoltan/Development/wx/src/common/init.cpp:460
> 0x08395273 2
> wxEntry() /home/zoltan/Development/wx/src/common/init.cpp:472
> 0x08395479 1
> main() /home/zoltan/Development/DBusCPPTest/src/main_app.cpp:42
> 0x0808438b
> 
> 
> Thanks.
> br,
> -zoltan.
> 
> On Wed, Sep 9, 2009 at 1:35 AM, Andreas Volz<li...@br...>
> wrote:
> > Am Tue, 8 Sep 2009 18:34:11 +0500 schrieb Zoltan Bencik:
> >
> > Hello Zoltan,
> >
> > I suggest you should compile dbus-c++ with debug option (--configure
> > --enable-debug), your application with -O0 -ggdb and run it in gdb.
> >
> > This would tell us all a lot of useful information.
> >
> > regards
> >        Andreas
> >
> >> Hello All,
> >>
> >> I'm trying to mount and unmount devices through dbus-c++ binding,
> >> using DeviceKit.Disks.Device interface methods.
> >> While trying to unmount device, I get a 'SIGTRAP' signal.
> >> Can anybody show me what I'm doing wrong in this code?
> >>
> >> Thanks, any help is very appreciated.
> >>
> >>
> >> // Proxy implementation
> >> DisksDeviceProxy::DisksDeviceProxy(DBus::Connection &connection,
> >> const char *object_path)
> >> : DBus::InterfaceProxy("org.freedesktop.DeviceKit.Disks"),
> >>   DBus::ObjectProxy(connection, object_path,
> >> "org.freedesktop.DeviceKit.Disks.Device")
> >> {
> >> }
> >>
> >> // Mount device
> >> void DisksDeviceProxy::MountDevice(const char *fstype,
> >> std::vector<std::string> &options)
> >> {
> >>       ::DBus::CallMessage call;
> >>       ::DBus::MessageIter wi = call.writer();
> >>
> >>       wi << fstype;
> >>       wi << options;
> >>       call.member("FilesystemMount");
> >>       ::DBus::Message ret = invoke_method (call);
> >>       ::DBus::MessageIter ri = ret.reader();
> >> }
> >>
> >> // Unmount device
> >> void DisksDeviceProxy::UnMountDevice(std::vector<std::string>
> >> &options) {
> >>       ::DBus::CallMessage call;
> >>       ::DBus::MessageIter wi = call.writer();
> >>
> >>       wi << options;
> >>       call.member("FilesystemUnmount");
> >>       ::DBus::Message ret = invoke_method (call); // Signaled
> >> SIGTRAP right here ::DBus::MessageIter ri = ret.reader();
> >> }
> >>
> >> And here is the code, how I'm trying to unmount device:
> >> //-- START
> >> DBus::BusDispatcher dispatcher;
> >> DBus::default_dispatcher = &dispatcher;
> >>
> >> DBus::Connection conn = DBus::Connection::SystemBus();
> >>
> >> DisksDeviceProxy devkit(conn,
> >> "/org/freedesktop/DeviceKit/Disks/devices/sdb1"); // for now, just
> >> hard coded value of my USB device
> >> std::vector<std::string>options;
> >> devkit.UnMountDevice(options);
> >> //-- END
> >>
> >> ------------------------------------------------------------------------------
> >> Let Crystal Reports handle the reporting - Free Crystal Reports
> >> 2008 30-Day trial. Simplify your report design, integration and
> >> deployment
> >> - and focus on what you do best, core application coding. Discover
> >> what's new with Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> >> _______________________________________________
> >> dbus-cplusplus-devel mailing list
> >> dbu...@li...
> >> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
> >>
> >
> > ------------------------------------------------------------------------------
> > Let Crystal Reports handle the reporting - Free Crystal Reports
> > 2008 30-Day trial. Simplify your report design, integration and
> > deployment - and focus on what you do best, core application
> > coding. Discover what's new with Crystal Reports now.
> >  http://p.sf.net/sfu/bobj-july
> > _______________________________________________
> > dbus-cplusplus-devel mailing list
> > dbu...@li...
> > https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
> >
> 

Re: [dbus-cplusplus-devel] Calling DeviceKit methods

[Zoltan B. <zol...@gm...>]

Hello Andreas,

Thanks for your kind response.

It seems like the GUI library(wxWidgets on Linux, wxGTK build) I'm
using is causing some problems(not sure).
Could you please tell me if my dbus-c++ usage is correct from the code
listed below?
Maybe I missed to register some callbacks, which I have to handle, or
passing method  parameters incorrectly,
or anything else.
GUI library throws me an assert, which has to deal with even notifiers.
I tried to use dbus-c++ in console application, and UnMount worked just fine.

Here is the stack trace from Eclipse IDE, when I try to call invoke_method.
I don't think it will be any helpful, since it's trace when GUI is about to die.

Thread [1] (Suspended)	
	22 pthread_mutex_unlock()  0x00ab51a0	
	21 _dl_open()  0x008f69eb	
	20 do_dlopen()  0x00a22952	
	19 _dl_catch_error()  0x008f2806	
	18 __libc_dlopen_mode()  0x00a22b15	
	17 init()  0x009fb858	
	16 pthread_once()  0x00ab73f0	
	15 backtrace()  0x009fba45	
	14 wxStackWalker::SaveStack()
/home/zoltan/Development/wx/src/unix/stackwalk.cpp:169 0x083edb79
	13 wxGUIAppTraits::ShowAssertDialog()
/home/zoltan/Development/wx/src/gtk/utilsgtk.cpp:379 0x08216dd8
	12 ShowAssertDialog()
/home/zoltan/Development/wx/src/common/appbase.cpp:836 0x08363cd0
	11 wxAppConsole::OnAssertFailure()
/home/zoltan/Development/wx/src/common/appbase.cpp:445 0x08364042
	10 wxApp::OnAssertFailure()
/home/zoltan/Development/wx/src/gtk/app.cpp:556 0x0820556f
	9 wxOnAssert() /home/zoltan/Development/wx/src/common/appbase.cpp:711
0x08363df7
	8 wxEventLoop::~wxEventLoop()
/home/zoltan/Development/wx/src/gtk/evtloop.cpp:64 0x0830fedf
	7 wxEventLoopPtr::~wxEventLoopPtr()
/home/zoltan/Development/wx/src/common/appcmn.cpp:74 0x0826f6d5
	6 wxEventLoopTiedPtr::~wxEventLoopTiedPtr()
/home/zoltan/Development/wx/src/common/appcmn.cpp:74 0x082705f1
	5 wxAppBase::MainLoop()
/home/zoltan/Development/wx/src/common/appcmn.cpp:312 0x0826fe7a
	4 wxAppBase::OnRun()
/home/zoltan/Development/wx/src/common/appcmn.cpp:367 0x0826f8b3
	3 wxEntry() /home/zoltan/Development/wx/src/common/init.cpp:460 0x08395273	
	2 wxEntry() /home/zoltan/Development/wx/src/common/init.cpp:472 0x08395479	
	1 main() /home/zoltan/Development/DBusCPPTest/src/main_app.cpp:42 0x0808438b


Thanks.
br,
-zoltan.

On Wed, Sep 9, 2009 at 1:35 AM, Andreas Volz<li...@br...> wrote:
> Am Tue, 8 Sep 2009 18:34:11 +0500 schrieb Zoltan Bencik:
>
> Hello Zoltan,
>
> I suggest you should compile dbus-c++ with debug option (--configure
> --enable-debug), your application with -O0 -ggdb and run it in gdb.
>
> This would tell us all a lot of useful information.
>
> regards
>        Andreas
>
>> Hello All,
>>
>> I'm trying to mount and unmount devices through dbus-c++ binding,
>> using DeviceKit.Disks.Device interface methods.
>> While trying to unmount device, I get a 'SIGTRAP' signal.
>> Can anybody show me what I'm doing wrong in this code?
>>
>> Thanks, any help is very appreciated.
>>
>>
>> // Proxy implementation
>> DisksDeviceProxy::DisksDeviceProxy(DBus::Connection &connection, const
>> char *object_path)
>> : DBus::InterfaceProxy("org.freedesktop.DeviceKit.Disks"),
>>   DBus::ObjectProxy(connection, object_path,
>> "org.freedesktop.DeviceKit.Disks.Device")
>> {
>> }
>>
>> // Mount device
>> void DisksDeviceProxy::MountDevice(const char *fstype,
>> std::vector<std::string> &options)
>> {
>>       ::DBus::CallMessage call;
>>       ::DBus::MessageIter wi = call.writer();
>>
>>       wi << fstype;
>>       wi << options;
>>       call.member("FilesystemMount");
>>       ::DBus::Message ret = invoke_method (call);
>>       ::DBus::MessageIter ri = ret.reader();
>> }
>>
>> // Unmount device
>> void DisksDeviceProxy::UnMountDevice(std::vector<std::string>
>> &options) {
>>       ::DBus::CallMessage call;
>>       ::DBus::MessageIter wi = call.writer();
>>
>>       wi << options;
>>       call.member("FilesystemUnmount");
>>       ::DBus::Message ret = invoke_method (call); // Signaled
>> SIGTRAP right here ::DBus::MessageIter ri = ret.reader();
>> }
>>
>> And here is the code, how I'm trying to unmount device:
>> //-- START
>> DBus::BusDispatcher dispatcher;
>> DBus::default_dispatcher = &dispatcher;
>>
>> DBus::Connection conn = DBus::Connection::SystemBus();
>>
>> DisksDeviceProxy devkit(conn,
>> "/org/freedesktop/DeviceKit/Disks/devices/sdb1"); // for now, just
>> hard coded value of my USB device
>> std::vector<std::string>options;
>> devkit.UnMountDevice(options);
>> //-- END
>>
>> ------------------------------------------------------------------------------
>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day trial. Simplify your report design, integration and deployment
>> - and focus on what you do best, core application coding. Discover
>> what's new with Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>> _______________________________________________
>> dbus-cplusplus-devel mailing list
>> dbu...@li...
>> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
>>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> dbus-cplusplus-devel mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
>

Re: [dbus-cplusplus-devel] Calling DeviceKit methods

[Andreas V. <li...@br...>]

Am Tue, 8 Sep 2009 18:34:11 +0500 schrieb Zoltan Bencik:

Hello Zoltan,

I suggest you should compile dbus-c++ with debug option (--configure
--enable-debug), your application with -O0 -ggdb and run it in gdb.

This would tell us all a lot of useful information.

regards
	Andreas

> Hello All,
> 
> I'm trying to mount and unmount devices through dbus-c++ binding,
> using DeviceKit.Disks.Device interface methods.
> While trying to unmount device, I get a 'SIGTRAP' signal.
> Can anybody show me what I'm doing wrong in this code?
> 
> Thanks, any help is very appreciated.
> 
> 
> // Proxy implementation
> DisksDeviceProxy::DisksDeviceProxy(DBus::Connection &connection, const
> char *object_path)
> : DBus::InterfaceProxy("org.freedesktop.DeviceKit.Disks"),
>   DBus::ObjectProxy(connection, object_path,
> "org.freedesktop.DeviceKit.Disks.Device")
> {
> }
> 
> // Mount device
> void DisksDeviceProxy::MountDevice(const char *fstype,
> std::vector<std::string> &options)
> {
> 	::DBus::CallMessage call;
> 	::DBus::MessageIter wi = call.writer();
> 
> 	wi << fstype;
> 	wi << options;
> 	call.member("FilesystemMount");
> 	::DBus::Message ret = invoke_method (call);
> 	::DBus::MessageIter ri = ret.reader();
> }
> 
> // Unmount device
> void DisksDeviceProxy::UnMountDevice(std::vector<std::string>
> &options) {
> 	::DBus::CallMessage call;
> 	::DBus::MessageIter wi = call.writer();
> 
> 	wi << options;
> 	call.member("FilesystemUnmount");
> 	::DBus::Message ret = invoke_method (call); // Signaled
> SIGTRAP right here ::DBus::MessageIter ri = ret.reader();
> }
> 
> And here is the code, how I'm trying to unmount device:
> //-- START
> DBus::BusDispatcher dispatcher;
> DBus::default_dispatcher = &dispatcher;
> 
> DBus::Connection conn = DBus::Connection::SystemBus();
> 
> DisksDeviceProxy devkit(conn,
> "/org/freedesktop/DeviceKit/Disks/devices/sdb1"); // for now, just
> hard coded value of my USB device
> std::vector<std::string>options;
> devkit.UnMountDevice(options);
> //-- END
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day trial. Simplify your report design, integration and deployment
> - and focus on what you do best, core application coding. Discover
> what's new with Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> dbus-cplusplus-devel mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
> 

[dbus-cplusplus-devel] Calling DeviceKit methods

[Zoltan B. <zol...@gm...>]

Hello All,

I'm trying to mount and unmount devices through dbus-c++ binding,
using DeviceKit.Disks.Device interface methods.
While trying to unmount device, I get a 'SIGTRAP' signal.
Can anybody show me what I'm doing wrong in this code?

Thanks, any help is very appreciated.


// Proxy implementation
DisksDeviceProxy::DisksDeviceProxy(DBus::Connection &connection, const
char *object_path)
: DBus::InterfaceProxy("org.freedesktop.DeviceKit.Disks"),
  DBus::ObjectProxy(connection, object_path,
"org.freedesktop.DeviceKit.Disks.Device")
{
}

// Mount device
void DisksDeviceProxy::MountDevice(const char *fstype,
std::vector<std::string> &options)
{
	::DBus::CallMessage call;
	::DBus::MessageIter wi = call.writer();

	wi << fstype;
	wi << options;
	call.member("FilesystemMount");
	::DBus::Message ret = invoke_method (call);
	::DBus::MessageIter ri = ret.reader();
}

// Unmount device
void DisksDeviceProxy::UnMountDevice(std::vector<std::string> &options)
{
	::DBus::CallMessage call;
	::DBus::MessageIter wi = call.writer();

	wi << options;
	call.member("FilesystemUnmount");
	::DBus::Message ret = invoke_method (call); // Signaled SIGTRAP right here
	::DBus::MessageIter ri = ret.reader();
}

And here is the code, how I'm trying to unmount device:
//-- START
DBus::BusDispatcher dispatcher;
DBus::default_dispatcher = &dispatcher;

DBus::Connection conn = DBus::Connection::SystemBus();

DisksDeviceProxy devkit(conn,
"/org/freedesktop/DeviceKit/Disks/devices/sdb1"); // for now, just
hard coded value of my USB device
std::vector<std::string>options;
devkit.UnMountDevice(options);
//-- END

Re: [dbus-cplusplus-devel] Problem with Introspectable

[Andreas V. <li...@br...>]

Am Sun, 23 Aug 2009 17:35:16 -0400 schrieb dorphell:

Hello dorphell,

I've also no idea why it's working on one system, but not on the other.
Did you try it on a third system?

Do you've an easy install package for me that I could try here?

regards
Andreas

> Hi Andreas,
> 
> We both use the same version from freedesktop.org.
> I tried the same exact version that worked for Milosz as well as the  
> latest/current git clone.
> Neither worked for me.
> 
> -dorphell
> 
> On Sun, 23 Aug 2009 16:16:50 -0400, Andreas Volz
> <li...@br...> wrote:
> 
> > Am Wed, 19 Aug 2009 11:01:13 -0400 schrieb dorphell:
> >
> > Hello dorphell,
> >
> > only to be sure. Do you both use the same DBus-C++ from gitorious or
> > fd.org?
> >
> > regards
> > Andreas
> 

Re: [dbus-cplusplus-devel] Problem with Introspectable

[dorphell <dor...@gm...>]

Hi Andreas,

We both use the same version from freedesktop.org.
I tried the same exact version that worked for Milosz as well as the  
latest/current git clone.
Neither worked for me.

On Sun, 23 Aug 2009 16:16:50 -0400, Andreas Volz <li...@br...>  
wrote:

> Am Wed, 19 Aug 2009 11:01:13 -0400 schrieb dorphell:
>
> Hello dorphell,
>
> only to be sure. Do you both use the same DBus-C++ from gitorious or
> fd.org?
>
> regards
> Andreas

Re: [dbus-cplusplus-devel] Problem with Introspectable

[Andreas V. <li...@br...>]

Am Wed, 19 Aug 2009 11:01:13 -0400 schrieb dorphell:

Hello dorphell,

only to be sure. Do you both use the same DBus-C++ from gitorious or
fd.org?

regards
Andreas

> 
> Hello all,
> 
> I'm having problems getting a dbus-c++ based app, Youki Media Player,
> to run properly -- and I was hoping someone here would have some
> ideas of what could be wrong.
> 
> Specifically, the problem is that the app won't register
> Introspectable for some reason, when it absolutely should and does on
> the developer's system (Milosz) with the same exact version of the
> app and dbus-c++ (we both compiled from the same source package).
> 
> With the 'echo' example in the dbus-c++ source tree, it works:
> ----------------
> $ export DBUSXX_VERBOSE=1
> $ ./echo-server
> dbus-c++: registering stubs for connection 0xf1ec40
> dbus-c++: added watch 0xf207e0 (off) fd=3 flags=2
> dbus-c++: added watch 0xf20870 (on) fd=3 flags=1
> dbus-c++: :1.31: registering bus name
> org.freedesktop.DBus.Examples.Echo dbus-c++: added timeout 0xf1f1f0
> (on) interval=25000 dbus-c++: removed timeout 0xf1f1f0
> dbus-c++: added timeout 0xf1eff0 (on) interval=25000
> dbus-c++: removed timeout 0xf1eff0
> dbus-c++: :1.31: added match rule
> destination='org.freedesktop.DBus.Examples.Echo'
> dbus-c++: adding interface org.freedesktop.DBus.EchoDemo
> dbus-c++: adding interface org.freedesktop.DBus.Introspectable
> dbus-c++: Introspectable
> dbus-c++: registering local object /org/freedesktop/DBus/Examples/Echo
> dbus-c++: entering dispatcher 0x616bc0
> dbus-c++: dispatching on 0xf1ec40
> dbus-c++: dispatching on 0xf1ec40
> dbus-c++: all dispatching done on 0xf1ec40
> ----------------
> 
> But when I run the app, for some reason I can't get the Introspectable
> even though it's in the app code and Milosz is certain there is no
> problem in Youki's code.
> I mean... it "just works" for him and the point at which it fails
> seems too trivial, it's such a basic fundamental constructor call,
> that we cannot find any way it can be wrong in the application
> itself... Almost like a hello-world program failing ;-)
> ----------------
> $ /usr/libexec/youki-mlibman-bin
> ...
> ... [normal application startup output]
> ...
> dbus-c++: registering stubs for connection 0xb58a70
> dbus-c++: glib: added watch 0xa21cf0 (off) fd=10 flags=2
> dbus-c++: glib: added watch 0xa21d20 (on) fd=10 flags=1
> dbus-c++: :1.42: registering bus name info.backtrace.Youki.MLibMan
> dbus-c++: glib: added timeout 0xa21c10 (on)
> dbus-c++: glib: removed timeout 0xa21c10
> dbus-c++: glib: added timeout 0xa21c10 (on)
> dbus-c++: glib: removed timeout 0xa21c10
> dbus-c++: :1.42: added match rule
> destination='info.backtrace.Youki.MLibMan'
> ...
> ... [more application startup output]
> ...
> dbus-c++: dispatching on 0xb58a70
> dbus-c++: dispatching on 0xb58a70
> dbus-c++: all dispatching done on 0xb58a70
> ----------------
> 
> ==> No "adding interface org.freedesktop.DBus.Introspectable"
> 
> We tried running it in gdb as well, trying to break out at the
> introspection.cpp line in the IntrospectableAdaptor constructor, but
> it didn't break out, as if it's not being called at all.
> 
> And as you can see, the dbus session is created. I can see the active
> info.backtrace.Youki.MLibMan in dbus-browser, but I can't introspec it
> (i.e. the browser pane shows empty).
> 
> And the app doesn't crash/exit. It keeps running (though the overall
> application can't function since the dbus communication with its GUI
> doesn't work)
> 
> If you would like to take a look at where in Youki
> DBus::IntrospectableAdaptor is called, here it is:
> 
> mlibmanager.hh ==>  http://pastebin.ca/1534526
> mlibmanager.cc ==>  http://pastebin.ca/1534528
> 
> We debugged this for many hours trying to narrow it down but have run
> out of ideas. If anyone has any suggestions, I'm willing to try
> anything.
> 
> Thanks in advance,
> dorphell
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day trial. Simplify your report design, integration and deployment
> - and focus on what you do best, core application coding. Discover
> what's new with Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> dbus-cplusplus-devel mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
> 

[dbus-cplusplus-devel] Problem with Introspectable

[dorphell <dor...@gm...>]

Hello all,

I'm having problems getting a dbus-c++ based app, Youki Media Player, to
run properly -- and I was hoping someone here would have some ideas of
what could be wrong.

Specifically, the problem is that the app won't register Introspectable
for some reason, when it absolutely should and does on the developer's
system (Milosz) with the same exact version of the app and dbus-c++ (we
both compiled from the same source package).

With the 'echo' example in the dbus-c++ source tree, it works:
----------------
$ export DBUSXX_VERBOSE=1
$ ./echo-server
dbus-c++: registering stubs for connection 0xf1ec40
dbus-c++: added watch 0xf207e0 (off) fd=3 flags=2
dbus-c++: added watch 0xf20870 (on) fd=3 flags=1
dbus-c++: :1.31: registering bus name org.freedesktop.DBus.Examples.Echo
dbus-c++: added timeout 0xf1f1f0 (on) interval=25000
dbus-c++: removed timeout 0xf1f1f0
dbus-c++: added timeout 0xf1eff0 (on) interval=25000
dbus-c++: removed timeout 0xf1eff0
dbus-c++: :1.31: added match rule
destination='org.freedesktop.DBus.Examples.Echo'
dbus-c++: adding interface org.freedesktop.DBus.EchoDemo
dbus-c++: adding interface org.freedesktop.DBus.Introspectable
dbus-c++: Introspectable
dbus-c++: registering local object /org/freedesktop/DBus/Examples/Echo
dbus-c++: entering dispatcher 0x616bc0
dbus-c++: dispatching on 0xf1ec40
dbus-c++: dispatching on 0xf1ec40
dbus-c++: all dispatching done on 0xf1ec40
----------------

But when I run the app, for some reason I can't get the Introspectable
even though it's in the app code and Milosz is certain there is no problem
in Youki's code.
I mean... it "just works" for him and the point at which it fails seems
too trivial, it's such a basic fundamental constructor call, that we
cannot find any way it can be wrong in the application itself... Almost
like a hello-world program failing ;-)
----------------
$ /usr/libexec/youki-mlibman-bin
...
... [normal application startup output]
...
dbus-c++: registering stubs for connection 0xb58a70
dbus-c++: glib: added watch 0xa21cf0 (off) fd=10 flags=2
dbus-c++: glib: added watch 0xa21d20 (on) fd=10 flags=1
dbus-c++: :1.42: registering bus name info.backtrace.Youki.MLibMan
dbus-c++: glib: added timeout 0xa21c10 (on)
dbus-c++: glib: removed timeout 0xa21c10
dbus-c++: glib: added timeout 0xa21c10 (on)
dbus-c++: glib: removed timeout 0xa21c10
dbus-c++: :1.42: added match rule
destination='info.backtrace.Youki.MLibMan'
...
... [more application startup output]
...
dbus-c++: dispatching on 0xb58a70
dbus-c++: dispatching on 0xb58a70
dbus-c++: all dispatching done on 0xb58a70
----------------

==> No "adding interface org.freedesktop.DBus.Introspectable"

We tried running it in gdb as well, trying to break out at the
introspection.cpp line in the IntrospectableAdaptor constructor, but it
didn't break out, as if it's not being called at all.

And as you can see, the dbus session is created. I can see the active
info.backtrace.Youki.MLibMan in dbus-browser, but I can't introspec it
(i.e. the browser pane shows empty).

And the app doesn't crash/exit. It keeps running (though the overall
application can't function since the dbus communication with its GUI
doesn't work)

If you would like to take a look at where in Youki
DBus::IntrospectableAdaptor is called, here it is:

mlibmanager.hh ==>  http://pastebin.ca/1534526
mlibmanager.cc ==>  http://pastebin.ca/1534528

We debugged this for many hours trying to narrow it down but have run out
of ideas. If anyone has any suggestions, I'm willing to try anything.

Thanks in advance,
dorphell

Re: [dbus-cplusplus-devel] leave() timeout

[Pierre-Luc B. <pie...@sa...>]

This solution was implemented and a new patch was made:
https://sourceforge.net/tracker/?func=detail&aid=2823377&group_id=236997&atid=1101684

On Tue, 2009-07-14 at 20:17 +0200, Redouane SOUM wrote:
> I already submitted a patch for that but it was for an old version of
> libdbus-c++.
> 
> The way to fix this issue is to add a file descriptor (a pipe) to the file
> descriptors we poll (fds).
> Then when we call leave() function we write in the pipe and it'll unblock
> the poll call.
> 
> Regards.
> 
> 
> 
> -----Message d'origine-----
> De : Pierre-Luc Bacon [mailto:pie...@sa...] 
> Envoyé : mardi 14 juillet 2009 17:01
> À : dbu...@li...
> Objet : [dbus-cplusplus-devel] leave() timeout
> 
> Calling leave() makes our application to wait for 10 sec. This can be a
> problem as a user might want to restart the application during that
> 10sec time frame. From eventloop.cpp, I see that:
> 
> int wait_min = 10000;
> 158 
> 159     DefaultTimeouts::iterator ti;
> 160 
> 161     _mutex_t.lock();
> 162 
> 163     for (ti = _timeouts.begin(); ti != _timeouts.end(); ++ti) {
> 164         if ( (*ti)->enabled() && (*ti)->interval() < wait_min)
> 165             wait_min = (*ti)->interval();
> 166     }
> 167 
> 168     _mutex_t.unlock();
> 169 
> 170     poll (fds, nfd, wait_min);
> 
> >From what I get of this portion of code, it loops to find the
> DefaultTimeout with the smallest time interval, then poll with that
> value.
> 
> Is this meant to be used internally for dbus-c++ only or could we 
> add_timeout(Timeout::Internal *) without fear of breaking the eventloop
> mechanism ?
> 
> Since:
>    
>  while (_running) {
>         do_iteration();
>  }
> 
> in enter() (eventloop-integration.cpp) and:
> 
> void BusDispatcher::leave()
> {
>     _running = false;
> }
> 
> wouldn't it be better to think of another way to leave the event loop in
> a more instantaneous manner ?
> 
> Pierre-Luc Bacon, 
> Savoir-Faire Linux
> http://www.sflphone.org
> 
> 
> ----------------------------------------------------------------------------
> --
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> 
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> dbus-cplusplus-devel mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
> 
> 
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited time, 
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize  
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> dbus-cplusplus-devel mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel

Re: [dbus-cplusplus-devel] leave() timeout

[Redouane S. <red...@fr...>]

I already submitted a patch for that but it was for an old version of
libdbus-c++.

The way to fix this issue is to add a file descriptor (a pipe) to the file
descriptors we poll (fds).
Then when we call leave() function we write in the pipe and it'll unblock
the poll call.

Regards.



-----Message d'origine-----
De : Pierre-Luc Bacon [mailto:pie...@sa...] 
Envoyé : mardi 14 juillet 2009 17:01
À : dbu...@li...
Objet : [dbus-cplusplus-devel] leave() timeout

Calling leave() makes our application to wait for 10 sec. This can be a
problem as a user might want to restart the application during that
10sec time frame. From eventloop.cpp, I see that:

int wait_min = 10000;
158 
159     DefaultTimeouts::iterator ti;
160 
161     _mutex_t.lock();
162 
163     for (ti = _timeouts.begin(); ti != _timeouts.end(); ++ti) {
164         if ( (*ti)->enabled() && (*ti)->interval() < wait_min)
165             wait_min = (*ti)->interval();
166     }
167 
168     _mutex_t.unlock();
169 
170     poll (fds, nfd, wait_min);

>From what I get of this portion of code, it loops to find the
DefaultTimeout with the smallest time interval, then poll with that
value.

Is this meant to be used internally for dbus-c++ only or could we 
add_timeout(Timeout::Internal *) without fear of breaking the eventloop
mechanism ?

Since:
   
 while (_running) {
        do_iteration();
 }

in enter() (eventloop-integration.cpp) and:

void BusDispatcher::leave()
{
    _running = false;
}

wouldn't it be better to think of another way to leave the event loop in
a more instantaneous manner ?

Pierre-Luc Bacon, 
Savoir-Faire Linux
http://www.sflphone.org


----------------------------------------------------------------------------
--
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize

details at: http://p.sf.net/sfu/Challenge
_______________________________________________
dbus-cplusplus-devel mailing list
dbu...@li...
https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel

Re: [dbus-cplusplus-devel] dbus-c++ echo sample fails

[Andreas V. <li...@br...>]

Am Wed, 8 Jul 2009 11:04:50 -0700 schrieb Bruce, Henry:

Yes, the example is bad. If someone provides a better one I'll commit
it.

regards
Andreas

> Sorry - just realized that applications set the main loop type. So
> echo sample still fails with Glib main loop. Maybe best just to
> remove it from the source tree. A sample that doesn't work is a
> barrier to adoption.
> 
> The properties sample works just fine. Not sure why the client needs
> to spawn a thread. Can someone explain?
> 
> I've got a Visual Studio build with the Glib main loop and the
> "properties" sample, but client / server comms are not working. Dbus
> monitor sees the client request, but server doesn't pick it up. I'll
> keep debugging.
> 
> Henry
> 
> 
> -----Original Message-----
> From: Bruce, Henry [mailto:hen...@in...] 
> Sent: Tuesday, July 07, 2009 12:05 PM
> To: dbu...@li...
> Subject: Re: [dbus-cplusplus-devel] dbus-c++ echo sample fails
> 
> Thanks to all who replied to my email. I've been digging deeper and
> have some questions and comments
> 
> 1. Does "main loop integration" apply to client and server
> applications and/or the binding library itself (i.e. dbus-c++ library)
> 
> 2. I switched to echo client and server applications to use the Glib
> main loop but still see the same "OOM" error on the client. As the
> dispatch enter and leave method are stubbed out in the Glib
> implementation, I created my own main loop in the client and server
> applications.
> 
> 3. Is it possible to change the main loop used by the binding? If so,
> are there instructions on how to do this ? I tried swapping out
> eventloop.h and for glib-integration.h in dispatcher.h and changing
> type of default_dispatcher accordingly, but got compiler errors
> (couldn't find any of the "Internal" sub classes).
> 
> 4. If I can work out how to do (3) for Glib, I can see a route to
> Visual Studio port.
> 
> Henry
> 
> 
> 
> -----Original Message-----
> From: Andreas Volz [mailto:li...@br...] 
> Sent: Thursday, July 02, 2009 12:45 PM
> To: dbu...@li...
> Subject: Re: [dbus-cplusplus-devel] dbus-c++ echo sample fails
> 
> Am Tue, 30 Jun 2009 12:46:17 -0700 schrieb Bruce, Henry:
> 
> Hello Henry,
> 
> To be honest I know this comment, but never experienced this error.
> And I use Dbus-C++ for a heavy communicating application.
> 
> Which main loop integration do you use? Try the Ecore or Glib loop.
> The default one is buggy.
> 
> regards
> Andreas
> 
> > All,
> >  
> > I have been evaluating dbus-c++. I really like the design - it makes
> > good use of C++ and is much easier to use the dbus-glib. I also like
> > the use of XML service description files. When I built and ran the
> > "echo" sample, the client failed after a few requests with a "not
> > enough memory" exception. When I looked at the source for
> > echo-client.cpp I saw the comment "For some strange reason, libdbus
> > frequently dies with an OOM". Sure enough, it had.
> > 
> > I'd really like to use dbus-c++, but it just doesn't seem stable
> > enough. Has anyone root caused this behavior?
> > 
> > Hoping that someone will save me from dbus-glib,
> > 
> > Thanks,
> > 
> > Henry Bruce
> > 
> > 
> > 
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > dbus-cplusplus-devel mailing list
> > dbu...@li...
> > https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
> > 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> dbus-cplusplus-devel mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
> 
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited
> time, vendors submitting new applications to BlackBerry App World(TM)
> will have the opportunity to enter the BlackBerry Developer
> Challenge. See full prize details at: http://p.sf.net/sfu/blackberry
> _______________________________________________
> dbus-cplusplus-devel mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge  
> This is your chance to win up to $100,000 in prizes! For a limited
> time, vendors submitting new applications to BlackBerry App World(TM)
> will have the opportunity to enter the BlackBerry Developer
> Challenge. See full prize details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> dbus-cplusplus-devel mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
> 

[dbus-cplusplus-devel] leave() timeout

[Pierre-Luc B. <pie...@sa...>]

Calling leave() makes our application to wait for 10 sec. This can be a
problem as a user might want to restart the application during that
10sec time frame. From eventloop.cpp, I see that:

int wait_min = 10000;
158 
159     DefaultTimeouts::iterator ti;
160 
161     _mutex_t.lock();
162 
163     for (ti = _timeouts.begin(); ti != _timeouts.end(); ++ti) {
164         if ( (*ti)->enabled() && (*ti)->interval() < wait_min)
165             wait_min = (*ti)->interval();
166     }
167 
168     _mutex_t.unlock();
169 
170     poll (fds, nfd, wait_min);

>From what I get of this portion of code, it loops to find the
DefaultTimeout with the smallest time interval, then poll with that
value.

Is this meant to be used internally for dbus-c++ only or could we 
add_timeout(Timeout::Internal *) without fear of breaking the eventloop
mechanism ?

Since:
   
 while (_running) {
        do_iteration();
 }

in enter() (eventloop-integration.cpp) and:

void BusDispatcher::leave()
{
    _running = false;
}

wouldn't it be better to think of another way to leave the event loop in
a more instantaneous manner ?

Pierre-Luc Bacon, 
Savoir-Faire Linux
http://www.sflphone.org

Re: [dbus-cplusplus-devel] dbus-c++ echo sample fails

[Bruce, H. <hen...@in...>]

Sorry - just realized that applications set the main loop type. So echo sample still fails with Glib main loop. Maybe best just to remove it from the source tree. A sample that doesn't work is a barrier to adoption.

The properties sample works just fine. Not sure why the client needs to spawn a thread. Can someone explain?

I've got a Visual Studio build with the Glib main loop and the "properties" sample, but client / server comms are not working. Dbus monitor sees the client request, but server doesn't pick it up. I'll keep debugging.

Henry


-----Original Message-----
From: Bruce, Henry [mailto:hen...@in...] 
Sent: Tuesday, July 07, 2009 12:05 PM
To: dbu...@li...
Subject: Re: [dbus-cplusplus-devel] dbus-c++ echo sample fails

Thanks to all who replied to my email. I've been digging deeper and have some questions and comments

1. Does "main loop integration" apply to client and server applications and/or the binding library itself (i.e. dbus-c++ library)

2. I switched to echo client and server applications to use the Glib main loop but still see the same "OOM" error on the client. As the dispatch enter and leave method are stubbed out in the Glib implementation, I created my own main loop in the client and server applications.

3. Is it possible to change the main loop used by the binding? If so, are there instructions on how to do this ? I tried swapping out eventloop.h and for glib-integration.h in dispatcher.h and changing type of default_dispatcher accordingly, but got compiler errors (couldn't find any of the "Internal" sub classes).

4. If I can work out how to do (3) for Glib, I can see a route to Visual Studio port.

Henry



-----Original Message-----
From: Andreas Volz [mailto:li...@br...] 
Sent: Thursday, July 02, 2009 12:45 PM
To: dbu...@li...
Subject: Re: [dbus-cplusplus-devel] dbus-c++ echo sample fails

Am Tue, 30 Jun 2009 12:46:17 -0700 schrieb Bruce, Henry:

Hello Henry,

To be honest I know this comment, but never experienced this error. And
I use Dbus-C++ for a heavy communicating application.

Which main loop integration do you use? Try the Ecore or Glib loop. The
default one is buggy.

regards
Andreas

> All,
>  
> I have been evaluating dbus-c++. I really like the design - it makes
> good use of C++ and is much easier to use the dbus-glib. I also like
> the use of XML service description files. When I built and ran the
> "echo" sample, the client failed after a few requests with a "not
> enough memory" exception. When I looked at the source for
> echo-client.cpp I saw the comment "For some strange reason, libdbus
> frequently dies with an OOM". Sure enough, it had.
> 
> I'd really like to use dbus-c++, but it just doesn't seem stable
> enough. Has anyone root caused this behavior?
> 
> Hoping that someone will save me from dbus-glib,
> 
> Thanks,
> 
> Henry Bruce
> 
> 
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> dbus-cplusplus-devel mailing list
> dbu...@li...
> https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel
> 

------------------------------------------------------------------------------
_______________________________________________
dbus-cplusplus-devel mailing list
dbu...@li...
https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge  
This is your chance to win up to $100,000 in prizes! For a limited time, 
vendors submitting new applications to BlackBerry App World(TM) will have 
the opportunity to enter the BlackBerry Developer Challenge. See full prize 
details at: http://p.sf.net/sfu/blackberry
_______________________________________________
dbus-cplusplus-devel mailing list
dbu...@li...
https://lists.sourceforge.net/lists/listinfo/dbus-cplusplus-devel