The necessary review and integration work has not happened, and
we don't want to enshrine it in this unproven state.
It will be back when the world is ready for it.
Previously, the code only initialized the enumerator if the address
hadn't had cached addresses. But creating an enumerator cached the
addresses, so the second one failed to work.
Make the certificate and peer-certificate properties virtual, and add
peer-certificate-errors as well. Change the documentation on
peer-certificate to say that it's not set until after the handshake
succeeds (which means notify::peer-certificate can be used to tell
when a handshake has completed).
We were combining "allow un-notified closes" and "close without
notifying" into a single property, which meant that it was impossible
to "be liberal in what you accept and conservative in what you send".
Change require-close-notify to only be about the peer behavior, and
make our connections always close-notify properly when closing (while
noting that you can just close the base-io-stream directly if you want
to do an unclean close).
Trying to do this as a signal won't work well with either
GTlsCertificateDB (in which case looking up a certificate in the db is
a blocking/asynchronous act) or session resumption support (in which
case the certificate or lack thereof is part of the session definition
and so needs to be known immediately). Make the caller use
g_tls_connection_set_certificate() ahead of time (or when retrying)
instead.
Add a method to verify a certificate against a CA; this can be used
for apps that need to test against non-default CAs.
Also make the GTlsCertificate::issuer property virtual
This adds an extension point for TLS connections to gio, with a
gnutls-based implementation in glib-networking.
Full TLS support is still a work in progress; the current API is
missing some features, and parts of it may still be changed before
2.28.
https://bugzilla.gnome.org/show_bug.cgi?id=588189
GProxyConnection is a class that was added for proxy support;
g_socket_client_connect() returns a GSocketConnection, but in some
cases (eg, encrypted SOCKS), GProxy might return a GIOStream that is
not a GSocketConnection. In that case, GSocketClient would wrap the
stream up in a GProxyConnection, which is a subclass of
GSocketConnection but uses the input/output streams of the wrapped
connection.
GTlsConnection is not a GSocketConnection, so it has the same problem,
so it will need the same treatment. Rename the class to
GTcpWrapperStream, and make it public, so people can extract the base
stream from it when necessary.
(This is not ideal and GSocketClient will need to be revisited as an
API at some point...)
https://bugzilla.gnome.org/show_bug.cgi?id=588189
When interfacing with APIs that expect unix-style async I/O, it is
useful to be able to tell in advance whether a read/write is going to
block. This adds new interfaces GPollableInputStream and
GPollableOutputStream that can be implemented by a GInputStream or
GOutputStream to add _is_readable/_is_writable, _create_source, and
_read_nonblocking/_write_nonblocking methods.
Also, implement for GUnixInput/OutputStream and
GSocketInput/OutputStream
https://bugzilla.gnome.org/show_bug.cgi?id=634241
g_cancellable_create_source() returns a GSource that triggers when its
corresponding GCancellable is cancelled. This can be used with
g_source_add_child_source() to add cancellability to a source.
Port gasynchelper's FDSource to use this rather than doing its own
cancellable handling, and also fix up its callback argument order to
be more normal.
https://bugzilla.gnome.org/show_bug.cgi?id=634239
Otherwise you break the fallback + recommended distinction for a content
type, as you end up adding support for a given content type to *all* of
the applications claiming to support the supertype.
This ways UIs can differentiate between them, and show them in different
section.
- a recommended app is an application that claims to support a content
type directly, not by a supertype derivation.
- a fallback app is an application that claims to support a supertype of
a given content type.
So that if we already have a list of emblems we know we want to add to
the icon, we can use e.g. a for loop to add them all, without picking
the first and looping from the second.
https://bugzilla.gnome.org/show_bug.cgi?id=634504
Removing an extension point is an API and ABI break. In particular, it
causes (older) gvfs versions to fail loading with a linkage error from
ld which in turn makes the desktop unusable.
So this reinstate the extension point and API provided by it, but
deprecates and does not use it. So no functionality is changed.
This reverts parts of commit 9b262f1c5f.
Complaints-Also-To: Ryan Lortie <desrt@desrt.ca>
-gdbusmessage.c and gregistrysettingsbackend.c is updated to fix C99-style declarations
-also fixed typo for displaying registry entry in gregistrysettingsbackend.c (\% -> \\%)
If specified, the signal subscription is setup client-side but the match
rule is not sent to the server. This allows the caller to manually
register more detailed match rules.
glib is trying to move toward using microseconds-in-gint64 as its
universal time format.
No real API breaks here since GTimeSpec is new this unstable release
series.
Add g_simple_async_result_new_take_error and
g_simple_async_result_take_error, which take over ownership of the
given error. Based on a patch by Christian Persch.
https://bugzilla.gnome.org/show_bug.cgi?id=629247
This is similar to gconftool-2 -R, which is very handy
for collecting information for bug reports, etc. It is now
possible to say gsettings list-recursively org.foo.bar, and
this will produce a list of schemas, keys and values for
org.foo.bar and all its child and grandchild schemata,
recursively.
https://bugzilla.gnome.org/show_bug.cgi?id=632571
Add support for passing the full contents of the environment to the
primary instance (by storing it in the platform_data) when
G_APPLICATION_SEND_ENVIRONMENT is in the flags.
RFC 2782 says that if there is no SRV record for
_SERVICE._PROTOCOL.DOMAIN, you should fall back to trying just DOMAIN,
with the default port for SERVICE. Do that.
https://bugzilla.gnome.org/show_bug.cgi?id=629274
Otherwise, attempting to create a GSocketConnection from the socket
will likely return the wrong type, since the protocol won't match any
of the registered subtypes.
Also add the start of a GSocket test program (from davidz).
https://bugzilla.gnome.org/show_bug.cgi?id=627171
Makes explicit the fact that you are interacting with the individual
action rather than the group and removes potential namespace conflicts
with classes implementing the interface (like g_application_activate()
vs g_application_activate_action()).
Create the gobject property for it.
Tweak the logic of having a pending timeout at the time that the
application starts -- run the mainloop with a use count of zero if there
is a timeout active.
Provides access to the g_settings_get_range() functionality, converting
its return value to something that's reasonable for printing at the
console and potentially parseable. The format may change.
Bug #631264.
Prevent assertion messages from spewing forth and also ensure that we
exit with an error status in the event that the value was out of range.
Bug #631264.
Don't store the "none" value for flags into the compiled schema file.
"none" should never appear as a value -- no flags set is indicated by an
empty array.
Ensure that the strinfo is output in little-endian byte order on big
endian machines.
GSettings is now passing all of its tests on PowerPC.
Bug #630968 is closed.
GSettings relies on parts of the schema infromation remaining
unbyteswapped (the strinfo database, for example) while requiring other
parts to be in native order (the default value, constraints, etc.).
Lift the byteswapping into a place where we can do it selectively.
The test case was passing a guint16 to g_object_get() for a guint
property. That's invalid on all systems, although it works (more or
less) on little endian ones. On big endian it's a total no-go.
For GSettings.
Use the functionality introduced in the last commit to simplify our
notify dispatching and increase the safety of doing so (by ensuring that
the context is acquired in the current thread for the duration of the
dispatch).
This closes bugs #623400 and #629849.
Rewrite the GSettings tool.
Improvements/changes:
- simplify the code by performing common actions (like creating a
schema) in only one place instead of one per-command
- new features (list schemas, list keys, monitor multiple, etc)
- factor-out bash completion and implement in shellscript
- input validation: should never abort due to invalid inputs
Still to do:
- proper error checking for ranges/choices
- support for querying range/choice information
- bash completion support for enums
Closes bug #629289, possibly among others.
In its previous form, g_settings_list_schemas() was not useful as a tool
to prevent aborts due to using g_settings_new() with an invalid schema
name. This is because g_settings_list_scheams() also listed relocatable
schemas, and calling g_settings_new() for those would abort just the
same as if you called it for a non-existent schema.
Modify g_settings_list_schemas() so that it only returns schemas for
which it is safe to call g_settings_new(). Add another call for sake of
completeness: g_settings_list_relocatable_schemas().
Implement the second feature requested in the bug: silently ignore
override files that attempt to override schemas that are not currently
installed.
Also, support 'strictness' being optional for other errors when parsing
override files (ie: inability to open the file, unknown key name, parse
errors, out of range). We don't completely back out the file in this
case — as that is difficult with the current implementation — but just
ignore the override for the single key.
Implement the first of two features requested in the bug: when
encountering a broken .xml schema file, back out the changes in that
file and continue to parse other files.
This prevents a single broken .xml file from messing up GSettings for
everyone else.
Add a --strict option to get the old behaviour. Use this from the test
cases.
Move all the annotations over from gobject-introspection.
They will not be used directly by the introspection scanner for now,
instead they will be extracted by a script and updated manually
until introspection is properly integrated into the glib build
It doesn't really work right now because of a dbus-daemon(1) bug - see
the comment added in the TODO section of gdbusconnection.c. So revert
to old behavior. The downside is a lot of files in /tmp but right now
that's better than not being able to run tests in a loop.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Without this fix, the ./gdbus-connection test case occasionally fails, see
https://bugzilla.gnome.org/show_bug.cgi?id=629945#c5
like this
/gdbus/connection/basic: OK
/gdbus/connection/life-cycle: **
ERROR:gdbus-connection.c:223:test_connection_life_cycle: assertion failed:
(!quit_mainloop_fired)
cleaning up bus with pid 21794
Aborted (core dumped)
because the callback didn't happen on the same thread as where we are
running the loop.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Since we make message buses come and go, we need to ensure that the
singleton connection instance goes away before attempting to call
g_bus_get_sync() or similar.
Signed-off-by: David Zeuthen <davidz@redhat.com>
When under load, a one second timeout is just not enough. This can be
observed by e.g. restarting a CPU- and IO-intensive application like a
web browser with many tabs while running the test cases. Therefore,
bump the timeouts to 30 seconds.
Signed-off-by: David Zeuthen <davidz@redhat.com>
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>
It looks like the deserialisation function in GSocketControlMessage can
potentially leak a reference to the class structure of a
GSocketControlMessage subclass (although the particular code path is
probably never hit).
Clean up the code a bit.
Also, make sure that the GUnixCredentialsMessage type is registered
before attempting deserialisation.
Closes bug #629687.
==7269== 144 bytes in 6 blocks are definitely lost in loss record 1,282 of 1,325
==7269== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==7269== by 0x4056B74: g_malloc (gmem.c:164)
==7269== by 0x406EDB6: g_slice_alloc (gslice.c:842)
==7269== by 0x406EDFB: g_slice_alloc0 (gslice.c:854)
==7269== by 0x413C627: g_type_create_instance (gtype.c:1867)
==7269== by 0x412276A: g_object_constructor (gobject.c:1480)
==7269== by 0x4121E5D: g_object_newv (gobject.c:1264)
==7269== by 0x4121BD3: g_object_new (gobject.c:1176)
==7269== by 0x417CFB9: g_credentials_new (gcredentials.c:156)
==7269== by 0x41D9DBC: g_unix_credentials_message_deserialize (gunixcredentialsmessage.c:149)
==7269== by 0x41C422C: g_socket_control_message_deserialize (gsocketcontrolmessage.c:198)
==7269== by 0x41BFCE3: g_socket_receive_message (gsocket.c:3289)
==7269== by 0x41D99CE: g_unix_connection_receive_credentials (gunixconnection.c:476)
==7269== by 0x41FA829: _g_dbus_auth_run_server (gdbusauth.c:987)
==7269== by 0x4205DDB: initable_init (gdbusconnection.c:2196)
Bug #629689.
These functions are meant to replace the read_until() flavour, with the
following improvements:
- consistency between the synchronous and asynchronous versions as to
if the separator character is read (it never is).
- support for using a nul byte as a separator character by way of
addition of a length parameter which allows stop_chars to be treated
as a byte array rather than a nul-terminated string.
The read_until() functions are not yet formally deprecated, but a note
has been added to the documentation warning not to use them as they will
be in the future.
This is bug #584284.
GSettings internally assumed that a change in key writability implied a
change in value. That may be true for some backends. Let those
backends deal with the situation for themselves.
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>
- can not extend schemas that already have paths
- can not form list of schemas that already have paths
- the path of a list schema, if given, must end with ':/'
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>
Since the previous commit, the g_unix_connection_send_credentials() /
g_unix_connection_receive_credentials() functions now also works on
FreeBSD since GUnixCredentialsMessage now works there.
The main idea is that the g_unix_connection_send_credentials() /
g_unix_connection_receive_credentials() functions are the "main" API
for getting credentials (one way or the other). So it's better to
avoid advertising where it is currently implemented.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Otherwise things probably won't work in a garbage-collected world
(consider the trivial GC that never collects garbage).
This commit breaks GDBusServer ABI. No known released software is
using this code.
Signed-off-by: David Zeuthen <davidz@redhat.com>
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>
Don't actually use this yet as that will require a couple of
modifications to the filter function signature. This is part of the
bug-fix for
https://bugzilla.gnome.org/show_bug.cgi?id=624546#c8
Signed-off-by: David Zeuthen <davidz@redhat.com>
==23341== 65 bytes in 3 blocks are definitely lost in loss record 927 of 1,020
==23341== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==23341== by 0x4057094: g_malloc (gmem.c:134)
==23341== by 0x40573DB: g_malloc_n (gmem.c:281)
==23341== by 0x40717FC: g_strdup (gstrfuncs.c:101)
==23341== by 0x4147F56: value_lcopy_string (gvaluetypes.c:313)
==23341== by 0x4123F0B: g_object_get_valist (gobject.c:1643)
==23341== by 0x41240FF: g_object_get (gobject.c:1731)
==23341== by 0x804C39E: test_basic (gdbus-proxy.c:522)
Bug #628331.
==23341== 85 (24 direct, 61 indirect) bytes in 1 blocks are definitely lost in loss record 900 of 971
==23341== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==23341== by 0x4057094: g_malloc (gmem.c:134)
==23341== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==23341== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==23341== by 0x403A751: g_error_new_valist (gerror.c:54)
==23341== by 0x403AAD4: g_set_error (gerror.c:240)
==23341== by 0x420B807: decode_method_reply (gdbusconnection.c:4774)
==23341== by 0x420C2BA: g_dbus_connection_call_sync (gdbusconnection.c:5188)
==23341== by 0x421B7C9: g_dbus_proxy_call_sync (gdbusproxy.c:2477)
==23341== by 0x804BD89: test_bogus_method_return (gdbus-proxy.c:430)
Bug #628331.
==29535== 56 (24 direct, 32 indirect) bytes in 1 blocks are definitely lost in loss record 1,112 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 0x406F364: g_slice_copy (gslice.c:858)
==29535== by 0x403A9B2: g_error_copy (gerror.c:160)
==29535== by 0x42066D3: initable_init (gdbusconnection.c:2314)
==29535== by 0x41A73E5: g_initable_init (ginitable.c:105)
==29535== by 0x41A7587: g_initable_new_valist (ginitable.c:218)
==29535== by 0x41A742A: g_initable_new (ginitable.c:138)
==29535== by 0x4206DCC: g_dbus_connection_new_for_address_sync (gdbusconnection.c:2585)
==29535== by 0x804D63A: test_nonce_tcp (gdbus-peer.c:1229)
==29535== 107 (24 direct, 83 indirect) bytes in 1 blocks are definitely lost in loss record 1,188 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 0x406F364: g_slice_copy (gslice.c:858)
==29535== by 0x403A9B2: g_error_copy (gerror.c:160)
==29535== by 0x42066D3: initable_init (gdbusconnection.c:2314)
==29535== by 0x41A73E5: g_initable_init (ginitable.c:105)
==29535== by 0x41A7587: g_initable_new_valist (ginitable.c:218)
==29535== by 0x41A742A: g_initable_new (ginitable.c:138)
==29535== by 0x4206DCC: g_dbus_connection_new_for_address_sync (gdbusconnection.c:2585)
==29535== by 0x804D8E8: test_nonce_tcp (gdbus-peer.c:1259)
==29535== 112 (24 direct, 88 indirect) bytes in 1 blocks are definitely lost in loss record 1,193 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 0x406F364: g_slice_copy (gslice.c:858)
==29535== by 0x403A9B2: g_error_copy (gerror.c:160)
==29535== by 0x42066D3: initable_init (gdbusconnection.c:2314)
==29535== by 0x41A73E5: g_initable_init (ginitable.c:105)
==29535== by 0x41A7587: g_initable_new_valist (ginitable.c:218)
==29535== by 0x41A742A: g_initable_new (ginitable.c:138)
==29535== by 0x4206DCC: g_dbus_connection_new_for_address_sync (gdbusconnection.c:2585)
==29535== by 0x804D79A: test_nonce_tcp (gdbus-peer.c:1248)
==29535== 73 (24 direct, 49 indirect) bytes in 1 blocks are definitely lost in loss record 1,152 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 0x406F364: g_slice_copy (gslice.c:858)
==29535== by 0x403A9B2: g_error_copy (gerror.c:160)
==29535== by 0x42066D3: initable_init (gdbusconnection.c:2314)
==29535== by 0x41A73E5: g_initable_init (ginitable.c:105)
==29535== by 0x41A7587: g_initable_new_valist (ginitable.c:218)
==29535== by 0x41A742A: g_initable_new (ginitable.c:138)
==29535== by 0x4206DCC: g_dbus_connection_new_for_address_sync (gdbusconnection.c:2585)
==29535== by 0x804C6CE: test_peer (gdbus-peer.c:803)
Bug #628331.
==6793== 32 (24 direct, 8 indirect) bytes in 1 blocks are definitely lost in loss record 779 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 0x41DB4F9: g_unix_fd_list_new (gunixfdlist.c:159)
==6793== by 0x804AADD: test_interface_method_call (gdbus-peer.c:172)
Bug #628331.
==4616== 46 (32 direct, 14 indirect) bytes in 1 blocks are definitely lost in loss record 193 of 305
==4616== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==4616== by 0x4057094: g_malloc (gmem.c:134)
==4616== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==4616== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==4616== by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==4616== by 0x412372A: g_object_constructor (gobject.c:1482)
==4616== by 0x4123147: g_object_newv (gobject.c:1347)
==4616== by 0x41236BB: g_object_new_valist (gobject.c:1463)
==4616== by 0x4122BB4: g_object_new (gobject.c:1181)
==4616== by 0x41B2D0F: g_network_address_new (gnetworkaddress.c:262)
==4616== by 0x8048A70: test_basic (network-address.c:10)
Bug #628331.
==14059== 96 bytes in 2 blocks are definitely lost in loss record 520 of 543
==14059== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==14059== by 0x4057094: g_malloc (gmem.c:134)
==14059== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==14059== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==14059== by 0x41385BB: g_type_create_instance (gtype.c:1867)
==14059== by 0x411E72A: g_object_constructor (gobject.c:1482)
==14059== by 0x411DE1D: g_object_newv (gobject.c:1266)
==14059== by 0x411DB93: g_object_new (gobject.c:1178)
==14059== by 0x42296AF: _g_local_file_input_stream_new (glocalfileinputstream.c:152)
==14059== by 0x422281F: g_local_file_read (glocalfile.c:1322)
==14059== by 0x418A8A9: open_read_async_thread (gfile.c:5050)
==14059== by 0x41B71BB: run_in_thread (gsimpleasyncresult.c:853)
==14059== by 0x41A5FBC: io_job_thread (gioscheduler.c:181)
==14059== by 0x407DCDE: g_thread_pool_thread_proxy (gthreadpool.c:314)
==14059== by 0x407C6B0: g_thread_create_proxy (gthread.c:1897)
==14059== by 0x57D918: start_thread (pthread_create.c:301)
==14059== by 0x4C6CBD: clone (clone.S:133)
Bug #628331.
==2464== 80 (16 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 515 of 547
==2464== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2464== by 0x4057094: g_malloc (gmem.c:134)
==2464== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2464== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2464== by 0x41385BB: g_type_create_instance (gtype.c:1867)
==2464== by 0x411E72A: g_object_constructor (gobject.c:1482)
==2464== by 0x411DE1D: g_object_newv (gobject.c:1266)
==2464== by 0x411DB93: g_object_new (gobject.c:1178)
==2464== by 0x4220D74: _g_local_file_new (glocalfile.c:310)
==2464== by 0x422C897: g_local_vfs_get_file_for_path (glocalvfs.c:84)
==2464== by 0x41CA91C: g_vfs_get_file_for_path (gvfs.c:94)
==2464== by 0x418C1B6: g_file_new_for_path (gfile.c:5898)
==2464== by 0x8049509: test1_thread (contexts.c:110)
==2464== 80 (16 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 516 of 547
==2464== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2464== by 0x4057094: g_malloc (gmem.c:134)
==2464== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2464== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2464== by 0x41385BB: g_type_create_instance (gtype.c:1867)
==2464== by 0x411E72A: g_object_constructor (gobject.c:1482)
==2464== by 0x411DE1D: g_object_newv (gobject.c:1266)
==2464== by 0x411DB93: g_object_new (gobject.c:1178)
==2464== by 0x4220D74: _g_local_file_new (glocalfile.c:310)
==2464== by 0x422C897: g_local_vfs_get_file_for_path (glocalvfs.c:84)
==2464== by 0x41CA91C: g_vfs_get_file_for_path (gvfs.c:94)
==2464== by 0x418C1B6: g_file_new_for_path (gfile.c:5898)
==2464== by 0x804964D: test_context_independence (contexts.c:144)
Bug #628331.
==2429== 49 (24 direct, 25 indirect) bytes in 1 blocks are definitely lost in loss record 276 of 355
==2429== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2429== by 0x4057094: g_malloc (gmem.c:134)
==2429== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2429== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2429== by 0x403A8A6: g_error_new_literal (gerror.c:117)
==2429== by 0x403AC31: g_set_error_literal (gerror.c:314)
==2429== by 0x4175525: g_buffered_input_stream_read_byte (gbufferedinputstream.c:880)
==2429== by 0x804A21A: test_read_byte (buffered-input-stream.c:153)
Bug #628331.
==2428== 256 bytes in 1 blocks are definitely lost in loss record 591 of 604
==2428== at 0x4005CD2: realloc (vg_replace_malloc.c:476)
==2428== by 0x40571A5: g_realloc (gmem.c:181)
==2428== by 0x4075287: g_string_maybe_expand (gstring.c:395)
==2428== by 0x40760D8: g_string_insert_c (gstring.c:1049)
==2428== by 0x4074D41: g_string_append_c_inline (gstring.h:153)
==2428== by 0x4075B3C: g_string_append_uri_escaped (gstring.c:822)
==2428== by 0x41A46AC: g_icon_to_string_tokenized (gicon.c:164)
==2428== by 0x41A498F: g_icon_to_string (gicon.c:252)
==2428== by 0x8049E1A: test_g_icon_serialize (g-icon.c:222)
Bug #628331.
==12763== 16,777,215 bytes in 1 blocks are possibly lost in loss record 357 of 357
==12763== at 0x4004F1B: calloc (vg_replace_malloc.c:418)
==12763== by 0x405711D: g_malloc0 (gmem.c:157)
==12763== by 0x8048ED6: test_basic (data-output-stream.c:40)
Bug #628331.
==2426== 45,034 bytes in 4,094 blocks are definitely lost in loss record 358 of 361
==2426== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2426== by 0x4057094: g_malloc (gmem.c:134)
==2426== by 0x40573DB: g_malloc_n (gmem.c:281)
==2426== by 0x4071ABD: g_strconcat (gstrfuncs.c:315)
==2426== by 0x804916A: test_read_lines (data-output-stream.c:83)
Bug #628331.
==12351== 45,045 bytes in 4,095 blocks are definitely lost in loss record 377 of 380
==12351== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==12351== by 0x4057094: g_malloc (gmem.c:134)
==12351== by 0x40573DB: g_malloc_n (gmem.c:281)
==12351== by 0x4071ABD: g_strconcat (gstrfuncs.c:315)
==12351== by 0x8049811: test_read_lines (data-input-stream.c:99)
Bug #628331.
==2415== 45,045 bytes in 4,095 blocks are definitely lost in loss record 393 of 399
==2415== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2415== by 0x4057094: g_malloc (gmem.c:134)
==2415== by 0x417FC29: g_data_input_stream_read_line (gdatainputstream.c:797)
==2415== by 0x8049874: test_read_lines (data-input-stream.c:111)
==12088== 360 bytes in 40 blocks are definitely lost in loss record 368 of 381
==12088== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==12088== by 0x4057094: g_malloc (gmem.c:134)
==12088== by 0x417FF4C: g_data_input_stream_read_until (gdatainputstream.c:914)
==12088== by 0x8049B6F: test_read_until (data-input-stream.c:182)
Bug #628331.
==2415== 165 (72 direct, 93 indirect) bytes in 3 blocks are definitely lost in loss record 373 of 399
==2415== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2415== by 0x4057094: g_malloc (gmem.c:134)
==2415== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2415== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2415== by 0x403A8A6: g_error_new_literal (gerror.c:117)
==2415== by 0x403AC31: g_set_error_literal (gerror.c:314)
==2415== by 0x417ED29: read_data (gdatainputstream.c:309)
==2415== by 0x417EE9D: g_data_input_stream_read_byte (gdatainputstream.c:344)
==2415== by 0x8049DEC: test_data_array (data-input-stream.c:263)
Bug #628331.
==10395== 80 (24 direct, 56 indirect) bytes in 1 blocks are definitely lost in loss record 529 of 561
==10395== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==10395== by 0x4057094: g_malloc (gmem.c:134)
==10395== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==10395== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==10395== by 0x403A751: g_error_new_valist (gerror.c:54)
==10395== by 0x403AAD4: g_set_error (gerror.c:240)
==10395== by 0x4230328: _g_local_file_output_stream_create (glocalfileoutputstream.c:628)
==10395== by 0x4227A04: g_local_file_create_readwrite (glocalfile.c:1388)
==10395== by 0x418974C: g_file_create_readwrite (gfile.c:1784)
==10395== by 0x8049FCD: test_g_file_create_readwrite (readwrite.c:187)
Bug #628331.
==8564== 24,000,000 bytes in 6 blocks are possibly lost in loss record 592 of 594
==8564== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==8564== by 0x4057094: g_malloc (gmem.c:134)
==8564== by 0x804AA37: test_corruption (converter-stream.c:589)
==8564== by 0x804B05B: test_roundtrip (converter-stream.c:652)
==9459== 25,165,824 bytes in 6 blocks are possibly lost in loss record 593 of 594
==9459== at 0x4005CD2: realloc (vg_replace_malloc.c:476)
==9459== by 0x40571A5: g_realloc (gmem.c:181)
==9459== by 0x41B08A3: array_resize (gmemoryoutputstream.c:501)
==9459== by 0x41B0A5D: g_memory_output_stream_write (gmemoryoutputstream.c:578)
==9459== by 0x41B57EF: g_output_stream_write (goutputstream.c:216)
==9459== by 0x41B591B: g_output_stream_write_all (goutputstream.c:268)
==9459== by 0x417D617: flush_buffer (gconverteroutputstream.c:359)
==9459== by 0x417D958: g_converter_output_stream_write (gconverteroutputstream.c:502)
==9459== by 0x41B5D7F: g_output_stream_real_splice (goutputstream.c:428)
==9459== by 0x41B5C6C: g_output_stream_splice (goutputstream.c:380)
==9459== by 0x804AB10: test_corruption (converter-stream.c:600)
==9785== 25,165,824 bytes in 6 blocks are possibly lost in loss record 592 of 592
==9785== at 0x4005CD2: realloc (vg_replace_malloc.c:476)
==9785== by 0x40571A5: g_realloc (gmem.c:181)
==9785== by 0x41B08A3: array_resize (gmemoryoutputstream.c:501)
==9785== by 0x41B0A5D: g_memory_output_stream_write (gmemoryoutputstream.c:578)
==9785== by 0x41B5D7F: g_output_stream_real_splice (goutputstream.c:428)
==9785== by 0x41B5C6C: g_output_stream_splice (goutputstream.c:380)
==9785== by 0x804ADF1: test_corruption (converter-stream.c:622)
==9785== by 0x804B06C: test_roundtrip (converter-stream.c:652)
Bug #628331.
==7540== 487 (64 direct, 423 indirect) bytes in 2 blocks are definitely lost in loss record 597 of 615
==7540== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==7540== by 0x4057094: g_malloc (gmem.c:134)
==7540== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==7540== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==7540== by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==7540== by 0x412372A: g_object_constructor (gobject.c:1482)
==7540== by 0x4123147: g_object_newv (gobject.c:1347)
==7540== by 0x41236BB: g_object_new_valist (gobject.c:1463)
==7540== by 0x41A756E: g_initable_new_valist (ginitable.c:214)
==7540== by 0x41A743E: g_initable_new (ginitable.c:138)
==7540== by 0x417B67A: g_charset_converter_new (gcharsetconverter.c:215)
==7540== by 0x804B043: test_charset (converter-stream.c:675)
Bug #628331.
==2396== 168 (92 direct, 76 indirect) bytes in 1 blocks are definitely lost in loss record 598 of 625
==2396== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2396== by 0x4057094: g_malloc (gmem.c:134)
==2396== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2396== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2396== by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==2396== by 0x412372A: g_object_constructor (gobject.c:1482)
==2396== by 0x4123147: g_object_newv (gobject.c:1347)
==2396== by 0x41236BB: g_object_new_valist (gobject.c:1463)
==2396== by 0x4122BB4: g_object_new (gobject.c:1181)
==2396== by 0x417C54D: g_converter_input_stream_new (gconverterinputstream.c:204)
==2396== by 0x804A53E: test_compressor (converter-stream.c:484)
Bug #628331.
==2396== 66 (24 direct, 42 indirect) bytes in 1 blocks are definitely lost in loss record 565 of 625
==2396== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2396== by 0x4057094: g_malloc (gmem.c:134)
==2396== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2396== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2396== by 0x403A8A6: g_error_new_literal (gerror.c:117)
==2396== by 0x403AC31: g_set_error_literal (gerror.c:314)
==2396== by 0x417BA38: g_charset_converter_convert (gcharsetconverter.c:344)
==2396== by 0x417BF67: g_converter_convert (gconverter.c:174)
==2396== by 0x417C9EB: g_converter_input_stream_read (gconverterinputstream.c:403)
==2396== by 0x41A7A17: g_input_stream_read (ginputstream.c:204)
==2396== by 0x41A7B43: g_input_stream_read_all (ginputstream.c:256)
==2396== by 0x804B0E4: test_charset (converter-stream.c:682)
Bug #628331.
==2396== 39 (24 direct, 15 indirect) bytes in 1 blocks are definitely lost in loss record 398 of 625
==2396== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2396== by 0x4057094: g_malloc (gmem.c:134)
==2396== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2396== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2396== by 0x403A8A6: g_error_new_literal (gerror.c:117)
==2396== by 0x403AC31: g_set_error_literal (gerror.c:314)
==2396== by 0x80498F7: g_compressor_converter_convert (converter-stream.c:244)
==2396== by 0x417BF67: g_converter_convert (gconverter.c:174)
==2396== by 0x417CBDE: g_converter_input_stream_read (gconverterinputstream.c:460)
==2396== by 0x41A7A17: g_input_stream_read (ginputstream.c:204)
==2396== by 0x804A832: test_compressor (converter-stream.c:545)
Bug #628331.
==2395== 64 bytes in 1 blocks are definitely lost in loss record 381 of 407
==2395== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2395== by 0x4005C66: realloc (vg_replace_malloc.c:476)
==2395== by 0x40571A5: g_realloc (gmem.c:181)
==2395== by 0x401D670: g_ptr_array_maybe_expand (garray.c:968)
==2395== by 0x401DD0B: g_ptr_array_add (garray.c:1225)
==2395== by 0x4199AA9: g_file_info_list_attributes (gfileinfo.c:646)
==2395== by 0x80491CE: test_g_file_info (g-file-info.c:76)
==2395== 132 (64 direct, 68 indirect) bytes in 1 blocks are definitely lost in loss record 396 of 407
==2395== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2395== by 0x4005C66: realloc (vg_replace_malloc.c:476)
==2395== by 0x40571A5: g_realloc (gmem.c:181)
==2395== by 0x401D670: g_ptr_array_maybe_expand (garray.c:968)
==2395== by 0x401DD0B: g_ptr_array_add (garray.c:1225)
==2395== by 0x4199A82: g_file_info_list_attributes (gfileinfo.c:642)
==2395== by 0x80492B7: test_g_file_info (g-file-info.c:86)
Bug #628331.
And use g_assert_[no_]error().
==2392== 49 (24 direct, 25 indirect) bytes in 1 blocks are definitely lost in loss record 451 of 573
==2392== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2392== by 0x4057094: g_malloc (gmem.c:134)
==2392== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2392== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2392== by 0x403A8A6: g_error_new_literal (gerror.c:117)
==2392== by 0x403AC31: g_set_error_literal (gerror.c:314)
==2392== by 0x41B7619: g_output_stream_set_pending (goutputstream.c:1198)
==2392== by 0x41B5799: g_output_stream_write (goutputstream.c:210)
==2392== by 0x41B590B: g_output_stream_write_all (goutputstream.c:268)
==2392== by 0x8049B54: verify_iostream (readwrite.c:110)
Bug #628331.
==2392== 38 (16 direct, 22 indirect) bytes in 1 blocks are definitely lost in loss record 369 of 573
==2392== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2392== by 0x4057094: g_malloc (gmem.c:134)
==2392== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2392== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2392== by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==2392== by 0x412372A: g_object_constructor (gobject.c:1482)
==2392== by 0x4122E1D: g_object_newv (gobject.c:1266)
==2392== by 0x4122B93: g_object_new (gobject.c:1178)
==2392== by 0x4225D74: _g_local_file_new (glocalfile.c:310)
==2392== by 0x4231897: g_local_vfs_get_file_for_path (glocalvfs.c:84)
==2392== by 0x41CF91C: g_vfs_get_file_for_path (gvfs.c:94)
==2392== by 0x41911B6: g_file_new_for_path (gfile.c:5898)
==2392== by 0x804A2B9: test_g_file_replace_readwrite (readwrite.c:235)
Bug #628331.
==2392== 38 (16 direct, 22 indirect) bytes in 1 blocks are definitely lost in loss record 368 of 573
==2392== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2392== by 0x4057094: g_malloc (gmem.c:134)
==2392== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2392== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2392== by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==2392== by 0x412372A: g_object_constructor (gobject.c:1482)
==2392== by 0x4122E1D: g_object_newv (gobject.c:1266)
==2392== by 0x4122B93: g_object_new (gobject.c:1178)
==2392== by 0x4225D74: _g_local_file_new (glocalfile.c:310)
==2392== by 0x4231897: g_local_vfs_get_file_for_path (glocalvfs.c:84)
==2392== by 0x41CF91C: g_vfs_get_file_for_path (gvfs.c:94)
==2392== by 0x41911B6: g_file_new_for_path (gfile.c:5898)
==2392== by 0x8049F23: test_g_file_create_readwrite (readwrite.c:183)
Bug #628331.
==2392== 38 (16 direct, 22 indirect) bytes in 1 blocks are definitely lost in loss record 367 of 573
==2392== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2392== by 0x4057094: g_malloc (gmem.c:134)
==2392== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2392== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2392== by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==2392== by 0x412372A: g_object_constructor (gobject.c:1482)
==2392== by 0x4122E1D: g_object_newv (gobject.c:1266)
==2392== by 0x4122B93: g_object_new (gobject.c:1178)
==2392== by 0x4225D74: _g_local_file_new (glocalfile.c:310)
==2392== by 0x4231897: g_local_vfs_get_file_for_path (glocalvfs.c:84)
==2392== by 0x41CF91C: g_vfs_get_file_for_path (gvfs.c:94)
==2392== by 0x41911B6: g_file_new_for_path (gfile.c:5898)
==2392== by 0x8049E30: test_g_file_open_readwrite (readwrite.c:153)
Bug #628331.
==2389== 84 (44 direct, 40 indirect) bytes in 1 blocks are definitely lost in loss record 299 of 315
==2389== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2389== by 0x4057094: g_malloc (gmem.c:134)
==2389== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2389== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2389== by 0x413D5BB: g_type_create_instance (gtype.c:1867)
==2389== by 0x412372A: g_object_constructor (gobject.c:1482)
==2389== by 0x4122E1D: g_object_newv (gobject.c:1266)
==2389== by 0x4122B93: g_object_new (gobject.c:1178)
==2389== by 0x41AF54C: g_memory_input_stream_new (gmemoryinputstream.c:199)
==2389== by 0x8048BD1: test_read_chunks (memory-input-stream.c:40)
Bug #628331.
==2389== 59 (24 direct, 35 indirect) bytes in 1 blocks are definitely lost in loss record 290 of 315
==2389== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2389== by 0x4057094: g_malloc (gmem.c:134)
==2389== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==2389== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==2389== by 0x403A8A6: g_error_new_literal (gerror.c:117)
==2389== by 0x403AC31: g_set_error_literal (gerror.c:314)
==2389== by 0x41AFD15: g_memory_input_stream_truncate (gmemoryinputstream.c:517)
==2389== by 0x41BAC0F: g_seekable_truncate (gseekable.c:174)
==2389== by 0x8049595: test_truncate (memory-input-stream.c:123)
Bug #628331.
==2530== 13 bytes in 1 blocks are definitely lost in loss record 373 of 681
==2530== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==2530== by 0x4057094: g_malloc (gmem.c:134)
==2530== by 0x40573DB: g_malloc_n (gmem.c:281)
==2530== by 0x40717FC: g_strdup (gstrfuncs.c:101)
==2530== by 0x4147F56: value_lcopy_string (gvaluetypes.c:313)
==2530== by 0x4123F0B: g_object_get_valist (gobject.c:1643)
==2530== by 0x41240FF: g_object_get (gobject.c:1731)
==2530== by 0x804A4BA: test_basic (gsettings.c:28)
Bug #628331.
Don't leak the ptr arrays in the map_sender_unique_name_to_signal_data_array
hash table.
==23440== 84 (20 direct, 64 indirect) bytes in 1 blocks are definitely lost in loss record 920 of 993
==23440== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==23440== by 0x4057094: g_malloc (gmem.c:134)
==23440== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==23440== by 0x401D2D0: g_ptr_array_sized_new (garray.c:799)
==23440== by 0x401D2AC: g_ptr_array_new (garray.c:783)
==23440== by 0x420834A: g_dbus_connection_signal_subscribe (gdbusconnection.c:3084)
Bug #628436.
==31063== 98 (24 direct, 74 indirect) bytes in 1 blocks are definitely lost in loss record 946 of 1,136
==31063== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==31063== by 0x4057094: g_malloc (gmem.c:134)
==31063== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==31063== by 0x4092383: g_variant_get_child_value (gvariant-core.c:847)
==31063== by 0x408BE9E: g_variant_get_variant (gvariant.c:709)
==31063== by 0x40903F5: g_variant_valist_get_nnp (gvariant.c:3767)
==31063== by 0x40907A9: g_variant_valist_get_leaf (gvariant.c:3884)
==31063== by 0x4090D10: g_variant_valist_get (gvariant.c:4065)
==31063== by 0x4090E59: g_variant_valist_get (gvariant.c:4100)
==31063== by 0x40911B6: g_variant_get_va (gvariant.c:4296)
==31063== by 0x40910BC: g_variant_get (gvariant.c:4248)
==31063== by 0x4208DAF: invoke_set_property_in_idle_cb (gdbusconnection.c:3676)
Bug #628346.
... 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.
Don't call LoadLibrary() on shell32.dll or kernel32.dll. kernel32.dll
is always loaded. Shell32.dll is also already loaded as glib links to
functions in it. So just call GetModuleHandle() on them.
For mlang.dll in win_iconv.c and winhttp.dll in gwinhttpvfs.c, always
try loading them from a complete path, from the Windows system
directory.
Use the "tool help" API to enumerate modules in gmodule-win32.c. It is
present in all Windows versions since Windows 2000, which is all we
support anyway. Thus no need to look that API up dynamically. Just
link to it normally. We can bin the fallback code that attempts to use
the psapi API.
Looks like we forgot to ref the returned GVariant in
g_dbus_proxy_call_finish().
It's a good question why code using g_dbus_proxy_call() and
g_dbus_proxy_call_finish() worked in the first place - probably the
answer is that no-one really used these APIs.
Signed-off-by: David Zeuthen <davidz@redhat.com>
==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.
==8221== 1,047 (672 direct, 375 indirect) bytes in 28 blocks are definitely lost in loss record 589 of 603
==8221== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==8221== by 0x4057094: g_malloc (gmem.c:134)
==8221== by 0x406F2D6: g_slice_alloc (gslice.c:836)
==8221== by 0x406F31B: g_slice_alloc0 (gslice.c:848)
==8221== by 0x403A8A6: g_error_new_literal (gerror.c:117)
==8221== by 0x403AC31: g_set_error_literal (gerror.c:314)
==8221== by 0x80499DC: g_compressor_converter_convert (converter-stream.c:267)
==8221== by 0x417BF67: g_converter_convert (gconverter.c:174)
==8221== by 0x417D7F0: g_converter_output_stream_write (gconverteroutputstream.c:428)
==8221== by 0x41B57DF: g_output_stream_write (goutputstream.c:216)
==8221== by 0x804A367: test_compressor (converter-stream.c:456)
Bug #628309.
==6793== 19 (8 direct, 11 indirect) bytes in 1 blocks are definitely lost in loss record 640 of 1,423
==6793== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==6793== by 0x4057094: g_malloc (gmem.c:134)
==6793== by 0x40573DB: g_malloc_n (gmem.c:281)
==6793== by 0x4073D1B: g_strsplit (gstrfuncs.c:2436)
==6793== by 0x4224A89: initable_init (gdbusserver.c:1040)
==6793== by 0x41A73F9: g_initable_init (ginitable.c:105)
==6793== by 0x41A759B: g_initable_new_valist (ginitable.c:218)
==6793== by 0x41A743E: g_initable_new (ginitable.c:138)
==6793== by 0x42238F5: g_dbus_server_new_sync (gdbusserver.c:484)
Bug #628328.
==6793== 16 bytes in 1 blocks are definitely lost in loss record 632 of 1,423
==6793== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==6793== by 0x4057094: g_malloc (gmem.c:134)
==6793== by 0x417FC29: g_data_input_stream_read_line (gdatainputstream.c:797)
==6793== by 0x41F99C1: _my_g_data_input_stream_read_line (gdbusauth.c:279)
==6793== by 0x41FA728: _g_dbus_auth_run_client (gdbusauth.c:759)
Bug #628327.
Turns out we are leaking non-floating GVariant instances returned by
get_property() functions.
Also avoid imprecise language such as "newly-allocated GVariant" as
this doesn't specify whether the variant can be floating or not.
Also see https://bugzilla.gnome.org/show_bug.cgi?id=627974 as it is
very related to this change.
Signed-off-by: David Zeuthen <davidz@redhat.com>
... that is, make it private. This makes sense because users are never
expected to create such objects themselves - only the GDBus core will
need this.
Signed-off-by: David Zeuthen <davidz@redhat.com>
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>
This allow application to take control over certain proxy protocol
handling. When a proxy protocol must be used and is found in the
application proxies, GSocketClient will simply TCP connect to the proxy
server and return the connection.
Reviewed-by: Dan Winship <danw@gnome.org>
Using this rather than g_socket_client_connect() or
g_socket_client_connect_to_host() allows #GSocketClient to
determine when to use application-specific proxy protocols.
Reviewed-by: Dan Winship <danw@gnome.org>
This functionnallity can be disabled using property enable-proxy. It
enumerates addresses using GSocketConnectable::proxy_enumerate() instead of
enumerate(). When the returned address is of type GProxyAddress (a type
based on GInetSocketAddress), it gets the proxy protocol handler using
g_proxy_get_default_for_protocol() and call connect() on it.
Reviewed-by: Dan Winship <danw@gnome.org>
This class inherit from GTcpConnection by refing the socket of
an existing GTcpConnection and wraps a custom GIOStream into itself. This
is to allow implementing proxies that alters data stream, like when using
GSSAPI privacy inside SOCKS5.
This way, if g_socket_connect() is called with a GProxyAddress,
g_socket_get_remote_address() will later return that same address.
Reviewed-by: Nicolas Dufresne <nicolas.dufresne@collabora.co.uk>
This patch implements method proxy_enumerate from GSocketConnectable for
all connectables (GNetworkAddress, GNetworkService, GInetSocketAddress
and GUnixSocketAddress).
Reviewed-by: Dan Winship <danw@gnome.org>
