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

[rony]

Hi Simon,

thank you very much indeed for your quick answer!


On 10.08.2011 11:42, Simon McVittie wrote:
> On Wed, 10 Aug 2011 at 11:31:49 +0200, rony wrote:
>   
>> The current implementation employs "dbus_server_set_watch_functions()",
>> but not "dbus_set_timeout_functions()", because there seems to be no
>> need for it.
>>     
> Well, that's something you're doing that most users of libdbus don't, so...
> Try implementing both, and if bugs still occur, *then* start debugging.
>
> (For instance, it's not impossible that deferred events are set up by adding
> a "timeout after 0 seconds", either now or in the future.)
>   
Oh, I see! Will do.

>>     * it seems that sometimes abends occur, where rarely a backtrace is
>>       given.
>>     
> I think you mean "aborts", not "abends" (not sure where that word came from).
>   
"abend" comes from the mainframe world, cf.<http://en.wikipedia.org/wiki/Abnormal_end>.

> For thread-safety, ensure that you have the latest D-Bus release from either
> the 1.4.x or 1.5.x (master) branch, to fix fd.o #38005; 
Will check (have 1.4.6, but that may not be new enough).

> and if you doubt your ability to debug threaded crashes, I strongly advise not using threads with
> libdbus.
>   
Sure. It is not so much not having the ability, but more the fact that
contrary to other development environments gdb-command-line debugging is
just "challenging" if the knowledge has rusted away. (Or  put in
different words: there is - again - a learning curve to get fully
acquainted again and then using it in command-line mode may take away
time resources, that would be needed for other projects who have starved
in the past weeks.)

[E.g. for another language binding to Java, dubbed BSF4ooRexx, that I
created, multithreading and debugging has been essential (driving tests
with 1,000 and more threads communicating between Java and Rexx, e.g.
running on different Rexx interpreter instances in the same process,
each Rexx interpreter instance employing multiple Rexx threads
communicating with different/same Java threads, and the like).]

> If at all possible I recommend using an existing main-loop implementation that
> is known to work well and has already been debugged, such as the ones in GLib
> and Qt.
>   
Yes, that would have been quite helpful all along. The reason why
staying away from GLib and Qt is to have a neutral language binding,
only dependent on the dbus reference implementation. One reason (but not
the only one) is to keep the eventual porting of the language binding to
Windows and MacOSX simple and independent of the availability of GLib or
Qt. (One interesting/attractive application would be having dbus
communications going on between apps on different machines with
different operating systems. So trying to keep everything as "simple" as
possible, especially w.r.t. dependencies.)

Again, thank you very much for your feedback, Simon!

Best regards

---rony