Commit Graph

62 Commits

Author SHA1 Message Date
Ravi Sankar Guntur
0ed2cdb0d9 Use g_queue_free_full() convenience function.
https://bugzilla.gnome.org/show_bug.cgi?id=667331

Signed-off-by: Ravi Sankar Guntur <ravi.g@samsung.com>
2012-01-09 19:27:39 -05:00
Simon McVittie
968ef5f5ff GDBusWorker: continue_writing: initialize flush_async_data if closing
This was a regression in commit f41178c6c: flush_async_data wasn't
necessarily NULL in the "don't flush" case.

Also move initialization of these variables up so that it's
unconditional, since that's easier to verify than checking
that each branch gets it right.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=664617
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
2011-11-23 11:20:15 +00:00
Simon McVittie
bae9928246 _g_dbus_worker_flush_sync: always flush if we need to
We didn't previously flush in a couple of cases where we should have
done:

* a write is running when flush is called: we should flush after it
  finishes

* writes have been made since the last flush, but none are pending or
  running right now: we should flush the underlying transport straight
  away

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662395
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Cosimo Alfarano <cosimo.alfarano@collabora.co.uk>
2011-11-21 18:12:30 +00:00
Simon McVittie
f41178c6c7 GDBusWorker: move flush async op into continue_writing()
This makes it easier to schedule a flush, by putting it on the same code
path as writing and closing.

Also change message_written to expect the lock to be held, since all
that's left in that function either wants to hold the lock or doesn't
care, and it's silly to release the lock immediately before calling
message_written, which just takes it again.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662395
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Cosimo Alfarano <cosimo.alfarano@collabora.co.uk>
2011-11-21 18:10:11 +00:00
Simon McVittie
301332168b schedule_write_in_worker_thread: require caller to lock; rename accordingly
When we use this function to schedule a flush, it'll be called
with the lock held. Releasing and immediately re-taking the lock would
be pointless.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662395
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Cosimo Alfarano <cosimo.alfarano@collabora.co.uk>
2011-11-21 17:42:58 +00:00
Simon McVittie
56eb16ff50 GDBusWorker: rename some functions
maybe_write_next_message now also closes, and I'm about to make it
consider whether to flush as well, so its name is increasingly
inappropriate. Similarly, write_message_in_idle_cb is a wrapper around
it which could do any of those things.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662395
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Cosimo Alfarano <cosimo.alfarano@collabora.co.uk>
2011-11-21 17:40:51 +00:00
Simon McVittie
18482ab17e GDBusWorker: distinguish between 3 sorts of output that might be pending
If the user calls flush_sync() with no messages in the queue, but an
async write call pending, then we ought to flush after that async write
returns (although we don't currently do that). If it was an async close
or flush that was pending, there's no need to flush (again) afterwards.
So, we need to distinguish.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662395
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Cosimo Alfarano <cosimo.alfarano@collabora.co.uk>
2011-11-21 17:21:35 +00:00
Alexandre Rostovtsev
dc89b51c2d _g_dbus_get_machine_id(): check /etc/machine-id too
machine-id can be in /etc or in /var/lib/dbus.

[amended with slightly revised error handling -smcv]

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=663928
2011-11-17 23:09:50 -05:00
Simon McVittie
0f01bef4b4 GDBusWorker: tolerate read errors while closing
My previous fix for GNOME#662100 was incomplete: it seems that with some
timings, the stream can be closed with an async read in-flight. This
can make the read fail immediately with G_IO_ERROR_CLOSED instead of
becoming cancelled.

This happens reliably on an embedded device, and rarely on my laptop;
repeating the test 100 times in quick succession reliably reproduces
the bug on my laptop.

It seems as though what we really want is to ignore read errors, once
we've established that we want to close the connection anyway - this
means that after asking to close, you're immune to exit-on-close,
which seems like a good rule.

An additional subtlety is that continuing to read after we know we
want to close is still required, otherwise we'll never emit ::closed.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662100
Bug-NB: NB#287088
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
2011-11-11 16:05:21 +00:00
Simon McVittie
214d249f40 GDBusWorker: debug on read errors if transport debugging is enabled
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662100
Bug-NB: NB#287088
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
2011-11-11 16:05:19 +00:00
Simon McVittie
5e0492da50 GDBusWorker: if a read was cancelled it means we closed the connection
This was a regression caused by my previous work on GDBusWorker thread-safety
(Bug #651268). The symptom is that if you disconnect a GDBusConnection
locally, the default implementation of GDBusConnection::closed
terminates your process, even though it shouldn't do that for
locally-closed connections; this is because GDBusWorker didn't think a
cancelled read was a local close.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=662100
Bug-NB: NB#287088
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: David Zeuthen <davidz@redhat.com>
2011-10-19 10:49:56 +01:00
Ryan Lortie
430c5635f2 g_thread_new: never fail
Remove the GError argument from g_thread_new() and abort on failure.
Introduce g_thread_try() for those who want to handle failure.
2011-10-13 01:00:57 -04:00
Ryan Lortie
015f4b4513 thread: nuke the concept of 'joinable'
And remove the 'joinable' argument from g_thread_new() and
g_thread_new_full().

Change the wording in the docs.  Clarify expectations for
(deprecated) g_thread_create().
2011-10-13 00:43:33 -04:00
Ryan Lortie
26a6b3c6ff gdbusprivate: fix a missed g_mutex_free()
This should have been changed to g_mutex_clear()
2011-10-04 20:08:14 -04:00
Ryan Lortie
5f48e2cde5 GDBus: switch to struct-embedded GMutex and GCond
Now that we have those, we should use them.

https://bugzilla.gnome.org/show_bug.cgi?id=660739
2011-10-04 11:13:46 -04:00
Matthias Clasen
0d1a92ca3d Add new thread creation API
Deprecate both g_thread_create functions and add
g_thread_new() and g_thread_new_full(). The new functions
expect a name for the thread.

Change GThreadPool, GMainContext and GDBus to create named threads.

https://bugzilla.gnome.org/show_bug.cgi?id=660635
2011-10-02 22:11:58 -04:00
Simon McVittie
e34e8a25a0 _g_dbus_worker_new: hold a ref until we have done the initial read
Otherwise, we could use-after-free the GDBusWorker, if its last-unref
is immediately after _g_dbus_worker_new returns (before the worker thread
does its initial read).

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=651268
Bug-NB: NB#271520
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Signed-off-by: David Zeuthen <davidz@redhat.com>
2011-09-16 12:00:22 -04:00
Simon McVittie
698eeb3ef6 GDBusWorker: as a precaution, access 'stopped' boolean atomically
This member is written in _g_dbus_worker_stop from arbitrary threads, and
read by the worker thread, so it should be accessed atomically.

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=651268
Bug-NB: NB#271520
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Signed-off-by: David Zeuthen <davidz@redhat.com>
2011-09-16 12:00:22 -04:00
Simon McVittie
c180ea13ae GDBusWorker: annotate more functions with lock/pending state
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=651268
Bug-NB: NB#271520
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Signed-off-by: David Zeuthen <davidz@redhat.com>
2011-09-16 12:00:22 -04:00
Simon McVittie
8097e2de85 GDBusConnection: delegate to the worker to close the stream
We can't safely close the output part of the I/O stream until any
pending write or flush has been completed. In the worst case, this could
lead to an assertion failure in the worker (when the close wins the
race) or not closing the stream at all (when the write wins the race).

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=651268
Bug-NB: NB#271520
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Signed-off-by: David Zeuthen <davidz@redhat.com>
2011-09-16 12:00:22 -04:00
Simon McVittie
a8f75f21b4 GDBusWorker: combine num_writes_pending with flush_pending
num_writes_pending was a counter, but it only took values 0 or 1, so make
it a boolean: it would never make sense to be trying to write out two
messages at the same time (they'd get interleaved).

Similarly, we can never be writing and flushing at the same time (that'd
mean we were flushing halfway through a message, which would be pointless)
so combine it with flush_pending too, calling the result output_pending.

Also assert that it takes the expected value whenever we change it,
and document the locking discipline used for it, including a subtle
case in write_message_in_idle_cb where it's not obvious at first glance
why we don't need the lock.

(Having the combined boolean at the top of the block of write-related
struct members improves struct packing on 64-bit platforms, by packing
read_num_ancillary_messages and output_pending into one word.)

Bug: https://bugzilla.gnome.org/show_bug.cgi?id=651268
Bug-NB: NB#271520
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Signed-off-by: David Zeuthen <davidz@redhat.com>
2011-09-16 12:00:22 -04:00
David Zeuthen
322e25b535 GDBus: Unref worker from worker-thread to avoid race
... otherwise we might end up using the worker after it has been
freed. Reported by Dan Winship and Colin Walters.

This fix uncovered a bug in the /gdbus/nonce-tcp test case so "fix"
that as well to use a better way of having one thread wait for another
(using quotes for the word "fix" since it's pretty hackish to
busy-wait in one thread to wait for another).

Signed-off-by: David Zeuthen <davidz@redhat.com>
2011-06-20 16:32:03 -04:00
Colin Walters
7ed328aaf0 gdbus: Avoid blocking on worker thread in connection initialization
I can't see a reason to spin until the worker thread runs, so don't.
This avoids ugly sched_yield() calls that show up in strace and
annoy me; the code is cleaner now too.

We now grab the types needed for the WebKit workaround in the
thread creation area, but only release them when the thread itself
exits.

https://bugzilla.gnome.org/show_bug.cgi?id=651650
2011-06-01 16:43:34 -04:00
David Zeuthen
0e352fdb18 Merge branch 'master' into gdbus-codegen 2011-04-29 12:01:35 -04:00
Matthias Clasen
53e3e111fd GDBusWorker: Improve struct packing 2011-04-12 10:00:03 -04:00
David Zeuthen
94b9071344 Start merging gdbus-codegen code
Signed-off-by: David Zeuthen <davidz@redhat.com>
2011-04-08 15:48:28 -04:00
David Zeuthen
0729260141 Silence a bunch of -Wunused-but-set-variable warnings
Signed-off-by: David Zeuthen <davidz@redhat.com>
2011-04-08 15:44:25 -04:00
Ted Gould
09ce9dc542 Bug 635626 – GDBus message idle can execute while flushes are pending
https://bugzilla.gnome.org/show_bug.cgi?id=635626

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-12-13 13:33:15 -05:00
Christian Persch
9e0c07870a Use g_simple_async_result_{new_,}take_error
Bug #633685.
2010-11-03 14:25:35 +01:00
Matthias Clasen
fe1186a842 message_to_write_data_free: Don't unref data->message if it is NULL
After the recent changes to message filtering, it can happen that
data->message is NULL when we get here.
2010-09-30 14:40:50 -04:00
David Zeuthen
f0b04acfd3 GDBusConnection: Avoid callbacks on finalized connection
Turns out that GDBusWorker will issue callbacks (in its own thread)
even after g_dbus_worker_stop() has been called. This would rarely
happen (and unreffing a connection is even rarer) so only saw this bug
occasionally when running the gdbus-connection test case in a loop.

Fix up this issue by maintaining a set of GDBusConnection objects that
are currently "alive" and do nothing in the callbacks if the passed
user_data pointer is not in this set.

Also attempted to fix up a race condition with
_g_object_wait_for_single_ref_do() and its use of GObject toggle
references - for now, just resort to busy waiting, thereby
sidestepping the toggle reference mess altogether.

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-09-23 15:16:56 -04:00
Tor Lillqvist
8a8cdd1d32 Add some more individual own header includes where required 2010-09-12 14:05:49 +03:00
David Zeuthen
0b74058fa3 Add work-around for Bug 627724
The root problem is with GObject - for now, just work around it in
GDBus. Also include a test-case. See

 https://bugzilla.gnome.org/show_bug.cgi?id=627724

for more information.

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-09-10 16:23:14 -04:00
David Zeuthen
7c66068544 GDBusMessage: Don't reset serial number when copying
Ryan pointed out that it's safe to do this because we have the
G_DBUS_SEND_MESSAGE_FLAGS_PRESERVE_SERIAL flag and that it simplifies
how filter functions work.

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-09-09 15:15:13 -04:00
David Zeuthen
c3371efcaa Bug 624546 – Modification of GDBusMessage in filter function
Rework filter functions as per

 https://bugzilla.gnome.org/show_bug.cgi?id=624546#c8

This commit breaks ABI. However, this ABI break affects only
applications using filter functions. The only known user of is dconf.

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-09-09 13:21:35 -04:00
Christian Persch
1f49f3fa34 Plug a mem leak
... and use g_error_matches().

==29535== 1,360 (408 direct, 952 indirect) bytes in 17 blocks are definitely lost in loss record 1,252 of 1,264
==29535==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==29535==    by 0x4057094: g_malloc (gmem.c:134)
==29535==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
==29535==    by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==29535==    by 0x403A751: g_error_new_valist (gerror.c:54)
==29535==    by 0x403AAD4: g_set_error (gerror.c:240)
==29535==    by 0x41C06C8: g_socket_send_message (gsocket.c:2967)
==29535==    by 0x421CB64: write_message_continue_writing (gdbusprivate.c:958)
==29535==    by 0x421CE2A: write_message_async (gdbusprivate.c:1049)
==29535==    by 0x421D4DD: maybe_write_next_message (gdbusprivate.c:1291)
==29535==    by 0x421D26B: message_written (gdbusprivate.c:1187)
==29535==    by 0x421D322: write_message_cb (gdbusprivate.c:1216)

Bug #628345.
2010-09-03 15:03:24 -04:00
Christian Persch
7a6f8bd3c3 Don't leak the FD list
==6793== 32 (24 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record 780 of 1,423
==6793==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==6793==    by 0x4057094: g_malloc (gmem.c:134)
==6793==    by 0x406F2D6: g_slice_alloc (gslice.c:836)
==6793==    by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==6793==    by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==6793==    by 0x412372A: g_object_constructor (gobject.c:1482)
==6793==    by 0x4122E1D: g_object_newv (gobject.c:1266)
==6793==    by 0x4122B93: g_object_new (gobject.c:1178)
==6793==    by 0x41DB582: g_unix_fd_list_new_from_array (gunixfdlist.c:191)
==6793==    by 0x421BFD6: _g_dbus_worker_do_read_cb (gdbusprivate.c:590)

Bug #628329.
2010-08-30 18:33:47 +02:00
David Zeuthen
3ff9894826 Bug 624546 – Modification of GDBusMessage in filter function
Allow modifying a GDBusMessage in a filter function and also add tests
for this. This breaks API but leaves ABI (almost) intact - at least
dconf's GSettings backend (the only big user I know of) will keep
working.

https://bugzilla.gnome.org/show_bug.cgi?id=624546

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-08-05 20:37:27 -04:00
Matthias Clasen
040bffed38 Fix build on !unix
There was one code block still referring to fd_list outside of
the ifdef G_OS_UNIX. Pointed out by Sam Thursfield in bug 627392.
2010-08-21 22:14:28 -04:00
Christian Persch
c56379264d Plug a mem leak in GDBusWorker
Free the read buffer.

==26538== 4,096 bytes in 1 blocks are definitely lost in loss record 781 of 781
==26538==    at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==26538==    by 0x4005C66: realloc (vg_replace_malloc.c:476)
==26538==    by 0x405244D: g_realloc (gmem.c:181)
==26538==    by 0x420E066: _g_dbus_worker_do_read_unlocked (gdbusprivate.c:780)
==26538==    by 0x420E1D1: _g_dbus_worker_do_read (gdbusprivate.c:812)
==26538==    by 0x420F14A: _g_dbus_worker_thread_begin_func (gdbusprivate.c:1318)
==26538==    by 0x420D2ED: invoke_caller (gdbusprivate.c:266)
==26538==    by 0x404DA7C: g_idle_dispatch (gmain.c:4224)
==26538==    by 0x4049FCD: g_main_dispatch (gmain.c:2119)
==26538==    by 0x404B2C1: g_main_context_dispatch (gmain.c:2672)
==26538==    by 0x404B716: g_main_context_iterate (gmain.c:2750)
==26538==    by 0x404BE7F: g_main_loop_run (gmain.c:2958)
==26538==    by 0x420D2B5: shared_thread_func (gdbusprivate.c:248)
==26538==    by 0x4077958: g_thread_create_proxy (gthread.c:1897)
==26538==    by 0x57D918: start_thread (pthread_create.c:301)
==26538==    by 0x4C6CBD: clone (clone.S:133)

Bug #627187.
2010-08-18 00:13:41 +02:00
David Zeuthen
8a3a4596e2 Bug 626748 – Use async methods for writing and handle EAGAIN
If sending a lot of data and/or the other peer is not reading it, then
socket buffers can overflow. This is communicated from the kernel by
returning EAGAIN. In GIO, it is modelled by g_output_stream_write()
and g_socket_send_message() returning G_IO_ERROR_WOULD_BLOCK.

It is also problematic that that we're using synchronous IO in the
shared GDBus IO thread. It means that one GDBusConnection can lock up
others.

It turns out that by porting from g_output_stream_write() to
g_output_stream_write_async() we fix the EAGAIN issue. For GSocket, we
still need to handle things manually (by creating a GSource) as
g_socket_send_message() is used.

We check the new behavior in Michael's producer/consumer test case (at
/gdbus/overflow in gdbus-peer.c) added in the last commit.

Also add a test case that sends and receives a 20 MiB message.

Also add a new `transport' G_DBUS_DEBUG option so it is easy to
inspect partial writes:

 $ G_DBUS_DEBUG=transport ./gdbus-connection -p /gdbus/connection/large_message
 [...]
 ========================================================================
 GDBus-debug:Transport:
   >>>> WROTE 128000 bytes of message with serial 4 and
        size 20971669 from offset 0 on a GSocketOutputStream
 ========================================================================
 GDBus-debug:Transport:
   >>>> WROTE 128000 bytes of message with serial 4 and
        size 20971669 from offset 128000 on a GSocketOutputStream
 ========================================================================
 GDBus-debug:Transport:
   >>>> WROTE 128000 bytes of message with serial 4 and
        size 20971669 from offset 256000 on a GSocketOutputStream
 [...]
 ========================================================================
 GDBus-debug:Transport:
   >>>> WROTE 43669 bytes of message with serial 4 and
        size 20971669 from offset 20928000 on a GSocketOutputStream
 [...]
 ========================================================================
 GDBus-debug:Transport:
   <<<< READ 16 bytes of message with serial 3 and
        size 20971620 to offset 0 from a GSocketInputStream
 ========================================================================
 GDBus-debug:Transport:
   <<<< READ 15984 bytes of message with serial 3 and
        size 20971620 to offset 16 from a GSocketInputStream
 ========================================================================
 GDBus-debug:Transport:
   <<<< READ 16000 bytes of message with serial 3 and
        size 20971620 to offset 16000 from a GSocketInputStream
 [...]
 ========================================================================
 GDBus-debug:Transport:
   <<<< READ 144000 bytes of message with serial 3 and
        size 20971620 to offset 20720000 from a GSocketInputStream
 ========================================================================
 GDBus-debug:Transport:
   <<<< READ 107620 bytes of message with serial 3 and
        size 20971620 to offset 20864000 from a GSocketInputStream
 OK

https://bugzilla.gnome.org/show_bug.cgi?id=626748

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-08-16 13:54:13 -04:00
David Zeuthen
d344ff9d67 Bug 626841 – Add test-case for non-socket GIOStream
Also fix a couple of bugs so it actually works.

https://bugzilla.gnome.org/show_bug.cgi?id=626841

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-08-13 14:01:36 -04:00
David Zeuthen
d52e1c33f7 GDBus: Add `return' debug option
This prints all GDBusMethodInvocation API usage and is normally used
with the `incoming' option. Example:

 # G_DBUS_DEBUG=incoming,return ./polkitd --replace
 Entering main event loop
 Connected to the system bus
 Registering null backend at priority -10
 [...]
 Acquired the name org.freedesktop.PolicyKit1
 [...]

 ========================================================================
 GDBus-debug:Incoming:
  <<<< METHOD INVOCATION org.freedesktop.PolicyKit1.Authority.RegisterAuthenticationAgent()
       on object /org/freedesktop/PolicyKit1/Authority
       invoked by name :1.26
       serial 299
 ========================================================================
 GDBus-debug:Return:
  >>>> METHOD ERROR org.freedesktop.PolicyKit1.Error.Failed
       message `Cannot determine session the caller is in'
       in response to org.freedesktop.PolicyKit1.Authority.RegisterAuthenticationAgent()
       on object /org/freedesktop/PolicyKit1/Authority
       to name :1.26
       reply-serial 299

 [...]

 ========================================================================
 GDBus-debug:Incoming:
  <<<< METHOD INVOCATION org.freedesktop.PolicyKit1.Authority.RegisterAuthenticationAgent()
       on object /org/freedesktop/PolicyKit1/Authority
       invoked by name :1.2402
       serial 25
 ========================================================================
 GDBus-debug:Return:
  >>>> METHOD RETURN
       in response to org.freedesktop.PolicyKit1.Authority.RegisterAuthenticationAgent()
       on object /org/freedesktop/PolicyKit1/Authority
       to name :1.2402
       reply-serial 25

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-08-04 16:59:26 -04:00
Matthias Clasen
33f7f6a748 Use glib infrastructure to parse debug flags
Proposed in bug 623319
2010-07-08 16:22:16 -04:00
Ryan Lortie
5b946e0504 gio/: fully remove gioalias hacks 2010-07-07 19:53:22 -04:00
David Zeuthen
62a1ccf526 Bug 618882 – No way to ensure that a message is sent
Add g_dbus_connection_flush{_finish,sync}().

https://bugzilla.gnome.org/show_bug.cgi?id=618882

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-07-07 15:03:03 -04:00
David Zeuthen
aab6d9ed1c GDBus: Handle autolaunching on UNIX/Freedesktop OSes
Also add a 'address' G_DBUS_DEBUG option that will print out useful
debug information such as

  GDBus-debug:Address: In g_dbus_address_get_for_bus_sync() for bus type `session'
  GDBus-debug:Address: env var DBUS_SESSION_BUS_ADDRESS is not set
  GDBus-debug:Address: env var DBUS_SYSTEM_BUS_ADDRESS is not set
  GDBus-debug:Address: env var DBUS_STARTER_BUS_TYPE is not set
  GDBus-debug:Address: Running `dbus-launch --autolaunch=05e508961149264c9b750a4c494aa6f7 --binary-syntax --close-stderr' to get bus address (possibly autolaunching)
  GDBus-debug:Address: dbus-launch output:
    0000: 75 6e 69 78  3a 61 62 73  74 72 61 63  74 3d 2f 74    unix:abstract=/t
    0010: 6d 70 2f 64  62 75 73 2d  77 42 41 6f  4b 59 49 52    mp/dbus-wBAoKYIR
    0020: 7a 75 2c 67  75 69 64 3d  30 34 30 64  31 33 66 33    zu,guid=040d13f3
    0030: 30 61 30 62  35 32 63 32  30 66 36 32  63 34 31 63    0a0b52c20f62c41c
    0040: 30 30 30 30  35 30 38 64  00 d2 38 00  00 01 00 40    0000508d..8....@
    0050: 05 00 00 00  00                                       .....
  GDBus-debug:Address: dbus-launch stderr output:
  14542: Autolaunch enabled (using X11).
  14542: --exit-with-session automatically enabled
  14542: Connected to X11 display ':0.0'
  14542: === Parent dbus-launch continues
  14542: Waiting for babysitter's intermediate parent
  14542: Reading address from bus
  14542: Reading PID from daemon
  14542: Saving x11 address
  14542: Created window 88080385
  14542: session file: /root/.dbus/session-bus/05e508961149264c9b750a4c494aa6f7-0
  14542: dbus-launch exiting
  GDBus-debug:Address: Returning address `unix:abstract=/tmp/dbus-wBAoKYIRzu,guid=040d13f30a0b52c20f62c41c0000508d' for bus type `session'

and

  GDBus-debug:Address: In g_dbus_address_get_for_bus_sync() for bus type `session'
  GDBus-debug:Address: env var DBUS_SESSION_BUS_ADDRESS is not set
  GDBus-debug:Address: env var DBUS_SYSTEM_BUS_ADDRESS is not set
  GDBus-debug:Address: env var DBUS_STARTER_BUS_TYPE is not set
  GDBus-debug:Address: Running `dbus-launch --autolaunch=05e508961149264c9b750a4c494aa6f7 --binary-syntax --close-stderr' to get bus address (possibly autolaunching)
  GDBus-debug:Address: dbus-launch output:
    0000: 75 6e 69 78  3a 61 62 73  74 72 61 63  74 3d 2f 74    unix:abstract=/t
    0010: 6d 70 2f 64  62 75 73 2d  77 42 41 6f  4b 59 49 52    mp/dbus-wBAoKYIR
    0020: 7a 75 2c 67  75 69 64 3d  30 34 30 64  31 33 66 33    zu,guid=040d13f3
    0030: 30 61 30 62  35 32 63 32  30 66 36 32  63 34 31 63    0a0b52c20f62c41c
    0040: 30 30 30 30  35 30 38 64  00 d2 38 00  00 01 00 40    0000508d..8....@
    0050: 05 00 00 00  00                                       .....
  GDBus-debug:Address: dbus-launch stderr output:
  14549: Autolaunch enabled (using X11).
  14549: --exit-with-session automatically enabled
  14549: Connected to X11 display ':0.0'
  14549: dbus-daemon is already running. Returning existing parameters.
  14549: dbus-launch exiting
  GDBus-debug:Address: Returning address `unix:abstract=/tmp/dbus-wBAoKYIRzu,guid=040d13f30a0b52c20f62c41c0000508d' for bus type `session'

Note that things work exactly like libdbus, e.g. from the
dbus-launch(1) man page:

  Whenever an autolaunch occurs, the application that had to start a
  new bus will be in its own little world; it can effectively end up
  starting a whole new session if it tries to use a lot of bus
  services. This can be suboptimal or even totally broken, depending
  on the app and what it tries to do.

  [...]

  You can always avoid autolaunch by manually setting
  DBUS_SESSION_BUS_ADDRESS. Autolaunch happens because the default
  address if none is set is "autolaunch:", so if any other address is
  set there will be no autolaunch. You can however include autolaunch
  in an explicit session bus address as a fallback, for example
  DBUS_SESSION_BUS_ADDRESS="something:,autolaunch:" - in that case if
  the first address doesn't work, processes will autolaunch. (The bus
  address variable contains a comma-separated list of addresses to
  try.)

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-07-06 17:03:36 -04:00
David Zeuthen
bd8d837f57 Bug 620913 – More control with G_DBUS_DEBUG
This commit adds the following G_DBUS_DEBUG flags

 - emission
 - incoming
 - call
 - signal
 - payload

https://bugzilla.gnome.org/show_bug.cgi?id=620913

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-07-01 14:37:16 -04:00
David Zeuthen
21d7ce97c3 GDBus: plug some memory leaks
These fixes makes udisks-daemon from udisks' gdbus-port branch, see

 http://cgit.freedesktop.org/udisks/log/?h=gdbus-port

handle 200 add/remove uevents generated by e.g.

 #!/bin/bash
 DEV=mmcblk0p1
 for n in `seq 200` ; do
     udevadm trigger --sysname-match=$DEV --action=remove
     udevadm trigger --sysname-match=$DEV --action=add
     echo foo $n
 done

without any substantial leaks.

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-06-30 16:39:32 -04:00
David Zeuthen
038d03cd08 Bug 623142 – Ensure ::new-connection runs before processing D-Bus messages
Without this guarantee, peer-to-peer connections are not very
useful. However, with this guarantee it's possible to export objects
in a handler for the GDBusServer::new-connection signal.

There are two caveats with this patch

 - it won't work on message bus connections
 - we don't queue up messages to be written

that can be addresses later if needed.

https://bugzilla.gnome.org/show_bug.cgi?id=623142

Signed-off-by: David Zeuthen <davidz@redhat.com>
2010-06-30 11:51:40 -04:00