- move choice of statfs vs statvfs from gio/glocalfile.c to configure.ac
- if statvfs is the choice, then don't check number of arguments to statfs()
- use choice in gio/gunixmounts.c as well
https://bugzilla.gnome.org/show_bug.cgi?id=617949
This function implements the following logic:
if (g_variant_is_floating (value))
g_variant_ref_sink (value);
which is used for consuming the return value of callbacks that may or
may not return floating references.
This patch also replaces a few instances of the above code with the new
function (GSettings, GDBus) and lifts a long-standing restriction on the
use of floating values as the return value for signal handlers by
improving g_value_take_variant().
https://bugzilla.gnome.org/show_bug.cgi?id=627974
The -e parameter to echo isn't recognized by echo in POSIX sh,
but isn't needed when no escaped characters need to be
interpreted.
This fixes building glib with a mingw cross compiler on Mac OS X.
https://bugzilla.gnome.org/show_bug.cgi?id=654085
-In gio/Makefile.am, the name for one of the filters for capturing the
sources for the GIO VS Project Files is corrected.
-Remove the GIO source file items in the VS project files templates as
a result for this change, and move the entry of the "new"
gregistrysettingsbackend.c into the filter in gio/Makefile.am
GAction is a read-only interface (as is visible by the lack of _set() functions
on its API). The properties on the interface currently force implementors to
support writing of the properties at construct time, however.
Lift that restriction.
Take advantage of this from GSimpleAction by nuking the set_property
function and setting the fields directly in the constructor.
This commit represents an API break to GAction in the following ways:
- the 'set_state' entry in the GActionInterface vtable has been
renamed to 'change_state'. The number and order of vtable items has
not otherwise changed.
- g_action_set_state() has been renamed to g_action_change_state() to
match the updated vtable entry.
- the "state" property of the GAction interface has been changed to
read-only to reflect the fact that g_action_set_state() no longer
exists.
- GSimpleActionClass has been hidden. GSimpleAction can no longer be
subclassed.
>> Rationale
g_action_set_state() has never been a true setter in the sense that
calling it will update the value of the "state" property. It has always
been closer to "request 'state' to be changed to this value" with
semantics defined by the implementor of the interface. This is why the
equivalent method in GActionGroup had its name changed from 'set' to
'change'. This change makes the two interfaces more consistent and
removes any implication about the effect that calling set_state() should
have on the 'state' property.
>> Impact
This incompatible API break was undertaken only because I strongly
suspect that it will go entirely unnoticed. If the break actually
affects anybody, then we will accommodate them (possibly going as far as
to revert this commit entirely).
The virtual table change only impacts implementors of GAction. I
strongly suspect that this is nobody (except for GSimpleAction).
The hiding of GSimpleActionClass only impacts impacts subclasses of
GSimpleAction. I strongly suspect that none of these exist.
The changing of the property to be read-only only affects people who
were trying to change the state by using GObject properties. I strongly
suspect that this is nobody at all.
The removal of the g_action_set_state() call is the most dangerous, but
I still suspect that it will impact nobody outside of GLib. If anybody
is impacted by this change then, at their request, I will reintroduce
the API as a deprecated alias for g_action_change_state().
To help cross compilation, don't use glib-genmarshal in our
build. This is easy now that we have g_cclosure_marshal_generic().
In gobject/, add gmarshal.[ch] to git (making the existing entry
points stubs).
In gio/, simply switch to using g_cclosure_marshal_generic().
https://bugzilla.gnome.org/show_bug.cgi?id=652168
... 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>
These will validate the resulting line, and throw a conversion error.
In practice these will likely be used by bindings, but it's good
for even C apps too that don't want to explode if that text file
they're reading into Pango actually has invalid UTF-8.
https://bugzilla.gnome.org/show_bug.cgi?id=652758
g_data_input_stream_read_line() and
g_data_input_stream_read_line_finish() don't do any encoding checks,
so we shouldn't call the returned value a "string" (which I'd like to
mean UTF-8). Annotate them as byte arrays and add encoding warnings
to the docstrings.
https://bugzilla.gnome.org/show_bug.cgi?id=652758
Matthew Bucknall pointed out
GDBusMessage does not serialize/deserialize double values correctly
on platforms with strict alignment constraints (in my particular
case, ARM926EJ-S).
This was reported in
https://bugzilla.gnome.org/show_bug.cgi?id=652197
Signed-off-by: David Zeuthen <davidz@redhat.com>
Rather than having the gtk-doc build machinery have a list of header
files to exclude, change the GLib build to dump a list of public
header files generated from the maintained Makefile.am files for
each of glib/, gobject/, gio/.
Also, for glib, always install glib-unix.h, even on non-Unix
platforms, for the same reason we install gwin32.h even on Unix.
https://bugzilla.gnome.org/show_bug.cgi?id=651745
See https://bugs.freedesktop.org/show_bug.cgi?id=37890#c6 where it was
discovered that dbus-send(1) actually doesn't work (either libdbus-1's
flush implementation or dbus-send(1)'s usage of it is broken) so it's
useful to have here.
Signed-off-by: David Zeuthen <davidz@redhat.com>
This avoids the generated types (e.g. ExampleAnimal, ExampleCat,
ExampleObject and ExampleObjectManagerClient) being referenced in the
core gio docs. This was requested by Matthias.
Signed-off-by: David Zeuthen <davidz@redhat.com>
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
In resolve_sync function in gthreadedresolver.c, if g_thread_pool_push
fails due to thread creation failure, we are just simply appending the
data to the queue of work to do. After the failure, we might wait
indefinitely in g_cond_wait. In case of g_thread_pool_push failure,
propagate the error so that this function does not blocks forever in
case of failure.
https://bugzilla.gnome.org/show_bug.cgi?id=651034
The fact that we return 0 here makes it clear that this
is not considered an error, so it makes sense to not
write these messages to stderr.
Proposed by Antoine Jacoutot,
https://bugzilla.gnome.org/show_bug.cgi?id=650882
The grouping in files/headers is not used anymore, and
the function attributes neither. Adapt abicheck scripts
and .def file generation rules accordingly.
There are some bugs caused by the way that gsettings-tool currently
attempts to help the user when they leave the quotes off of a string
value that they are setting.
Simplify the code to make it more robust and add some comments about why
it should be done this way.
https://bugzilla.gnome.org/show_bug.cgi?id=649915
For example, if setting a property on a skeleton from another thread
than where it was constructed, the idle handler responsible for
emitting the PropertiesChanged() signal could run immediately and
clear skeleton->priv->changed_properties_idle_source causing
g_source_unref() to be called with a NULL pointer. This race was
easily be fixed by adding a lock to the skeleton object.
In addition to fixing this race, also move the code for setting up the
idle handler to a class handler for the GObject::notify signal. This
change allows use of g_object_freeze_notify() and g_object_thaw_notify()
to perform atomic property changes from another thread than the one
that the skeleton was created in.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Don't drop resets from a GDelayedSettingsBackend when the writability
changes. Resets will always succeed, even against non-writable keys and
some people (gnome-screensaver) are using them in a way that they would
want them not to be forgotten.
This can easily happen if the owner of the remote object vanishes. Of
course, when that happens, user code is already notified (by e.g. the
notify::g-name-owner signal) so it can avoid using the proxy but
requiring that is a bit harsh. IOW, before this patch this critical
error was printed
GLib-GIO-CRITICAL **: g_dbus_gvariant_to_gvalue: assertion `value != NULL' failed
when that happened. With this patch, we just avoid setting the GValue
so the user will get the default value for its type instead. So, for
example, if the user code is getting a GVariant property on such a
defunct proxy, then he gets a NULL back. So unless said user code
checks the return value, criticals will still be printed if the NULL
GVariant is used for anything interesting.
Signed-off-by: David Zeuthen <davidz@redhat.com>
The code generator sprinkles a few asserts in its output of the form:
g_assert (prop_id - 1 >= 0 && prop_id - 1 < %d);\n
prop_id is unsigned, though, so this generates a compiler warning for
me.
This commit changes the code to merely check for prop_id != 0 instead of
prop_id - 1 >= 0
.. and add a C setter to do this. Also make the C getter return a
reference since the property may be set from another thread. Also
change the constructor to _not_ take a GDBusConnection since this is
something you almost always want to do _after_ creating it. The
API/ABI break is fine as there has never been a GLib release with this
type.
https://bugzilla.gnome.org/show_bug.cgi?id=648959
Signed-off-by: David Zeuthen <davidz@redhat.com>
_GNU_SOURCE must be defined before including any other (system)
header, so defining it in glib-unix.h (and hoping no one has included
anything else before that) is wrong. And the "#define _USE_GNU"
workaround for this problem in gnetworkingprivate.h is even wronger
(and still prone to failure anyway due to single-include guards).
Fix this by defining _GNU_SOURCE in config.h when building against
glibc. In theory this is bad because new releases of glibc may include
symbols that conflict with glib symbols, which could then cause
compile failures. However, most people only see new releases of glibc
when they upgrade their distro, at which point they also generally get
new releases of gcc, which have new warnings/errors to clean up
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=649201
GDesktopAppInfo violates the GObject rule that your C constructors
should just be thin wrappers around g_object_new(). While GKeyFile
isn't introspctable, this patch allows from JavaScript:
var app = new Gio.DesktopAppInfo({ filename: '/path/to/foo.desktop' });
https://bugzilla.gnome.org/show_bug.cgi?id=648425
When an old pre-thread-default-context API that takes an explicit
GMainContext wants to call a gio API, it must call
g_main_context_push_thread_default() before, and
g_main_context_pop_thread_default() after the gio call, so that the
gio method will return its result to the desired GMainContext.
But this fails for methods like g_socket_client_connect_async() that
make a chain of multiple async calls, since the pushed/popped context
will only affect the initial call.
Fix this by having GSimpleAsyncResult itself push/pop the context
around the callback invocation, so that if the callback queues another
async request, it will stay in the same context as the original one.
https://bugzilla.gnome.org/show_bug.cgi?id=646957
This is nice to have if using gtk-doc on the generated code. We could
also generate -sections.txt and .types files but we don't do that
right now...
Signed-off-by: David Zeuthen <davidz@redhat.com>
Specific changes
- Use get_type(), not get_gtype() for the GType function
- so we need to use the lower-case name type_ for properties called type
- Don't return a function pointer, just make the function returned
available instead
- Add (type) annotations in constructors so g-ir-scanner detects them as such
- Add (transfer none) annotations to property getters
- Add (out) annotations to D-Bus method call functions
Signed-off-by: David Zeuthen <davidz@redhat.com>
It's not that it's actually a bug to do so per se, strictly speaking,
it's just pointless and wasteful.
Signed-off-by: David Zeuthen <davidz@redhat.com>
A fairly typical pattern is to have code that does
foo_set_bar (object, "");
if (some_condition)
{
foo_set_bar (object, "yes");
}
where some_condition is often true every time @object is updated.
With this code, bar is essentially always "yes" but because of how
gdbus-codegen works, useless PropertiesChanged events got scheduled
and sent out. With this patch, we avoid that by always keeping the
original value around and comparing it only when we deem it's time to
send out the ::PropertiesChanged signal (typically in an idle but can
be forced by the user via flush()).
Also add a test case for this.
Signed-off-by: David Zeuthen <davidz@redhat.com>
More precisely, include this line
The license of this code is the same as for the source it was derived from.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Older versions of libdbus would let you construct an invalid
DBusMessage, but that's a bug, which will be fixed in 1.4.8/1.5.0.
Instead, construct a valid message of the same length, then replace
substrings in the serialized blob with their invalid counterparts.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=646326
Signed-off-by: David Zeuthen <davidz@redhat.com>
... this was causing a GDBus test-case to fail so now that it is
fixed, also reenable the test case.
https://bugzilla.gnome.org/show_bug.cgi?id=631379
Signed-off-by: David Zeuthen <davidz@redhat.com>
If g_bus_get_sync() fails in authentication (because e.g. the process
uid, doesn't match the expected in EXTERNAL), a secondary call to
g_bus_get_sync() would notice we aren't initialized, and try
to initialize.
The assertion here is just wrong; we now explicitly and clearly handle
both cases where we already have an error, or we already succeeded.
https://bugzilla.gnome.org/show_bug.cgi?id=635694
And use this for a) documentation purposes; and b) to preserve C ABI
when an interface is extended. See
https://bugzilla.gnome.org/show_bug.cgi?id=647577#c5
for more details. Also add test cases for this.
Signed-off-by: David Zeuthen <davidz@redhat.com>
This is because gtk-doc scans the function in the H file but reads the
docs from the C file. Annoying.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Call g_settings_sync() just before g_applcation_run() returns. This is
really the correct thing to do in every case that you're using GSettings
and it prevents every single application from having to do it for
themselves.
Closes bug #647419.
If GSettings is uninitialised then g_settings_sync() should very
obviously just return right away (rather than attempting to initialise
GSettings first).
Add a flag to essentially short-circuit g_application_register(). The
application makes no attempt to acquire the bus name or check for
existing instances with that name. The application is never considered
as being 'remote' and all requests are handled locally.
Closes#646985.
Several flaws were pointed out by Shaun McCance. We were
leaking handled arguments, and we were mishandling the last
argument, and we were actually skipping arguments too.
https://bugzilla.gnome.org/show_bug.cgi?id=647031
When using GOption to handle commandlines, we need to disable
the builtin help handling, since it calls exit(). Also mention
this particular pitfall in the docs.
For child schemas, verify that the named schema actually exists and
issue a warning if not. This error in schema files will cause runtime
errors when iterating over the list of child schemas and attempting to
instantiate each one.
This will move from being merely a warning to a hard error in the
future.
Bug #646039.
g_tls_certificate_list_new_from_file() was leaking the file contents,
and GSource was leaking the GSourcePrivate structure that got
created when using child sources.
Without getting into a debate about the reasons why you may or may not
want to use unsigned integers, it's sufficient to note that people have
been using them and requesting this functionality.
Bug #641755.
If we have an expected interface and receive a signal not mentioned in
the interface, simply drop it. This way, the application won't have to
check for the signal itself.
This was pointed out in
https://bugzilla.gnome.org/show_bug.cgi?id=642724#c5
Signed-off-by: David Zeuthen <davidz@redhat.com>
If the proxy has an GInterfaceInfo set, validate properties against it
so the application doesn't have to do it.
Signed-off-by: David Zeuthen <davidz@redhat.com>
* gio/gfileattribute.c: (_g_file_attribute_value_get_string,
_g_file_attribute_value_set_string): These use
G_FILE_ATTRIBUTE_TYPE_STRING, which is documented as UTF-8, so
document these private functions as using UTF-8.
* gio/gfileinfo.c: (g_file_info_get_attribute_string,
g_file_info_set_attribute_string, and stringv versions):
Document that the strings are UTF-8 because the implementation uses
those private functions, that use UTF-8.
This helps language bindings (such as glibmm) whose API
distinguishes between known and unknown encodings.
* gio/application.c (g_application_real_command_line): Check that the
default signal handler is not the current one before complaining, because
it is not unusual for overloads to call the base class implementation as
a matter of habit.
g_application_real_open() and g_application_real_activate() already do this
extra check.
Make the schema argument to gsettings list-recursively optional.
This allows to search for not exactly known keys by going
gsettings list-recursively | grep 'font'
These are the updates to the autotools files to
ensure the expansion of the GIO, GLib and GObject
project files (*.vcxproj, *.vcxproj.filters) and to
enable the distribution of the VS2010 project files
The actual VS2010 project files will follow shortly
We were considering explicitly configured defaults for parent types
after we already got results for the specific type we're interested in.
This resulted in the explicit default for text/plain to override all
system defaults for subtypes of text/plain, for example. The explicit
default should not apply to subtypes that have a system default.
https://bugzilla.gnome.org/show_bug.cgi?id=642797
Accept (and silently ignore) version attributes on <interface>
and <method> elements - these occur in the wild, and ignoring
them does not cost us anything.
We were getting our length zero, yet NULL-terminated arrays in
a twist in some places. Stop passing around ignored length arguments
at the same time.
https://bugzilla.gnome.org/show_bug.cgi?id=635099
This will help applications such as zeitgeist's datahub to collect
more complete information about application launches, as the "actor"
of a launch is important for zeitgeist's magic to work properly.
If we were the initial connection owner, unref will destroy the
connection immediately, and we may lose messages. Asynchronously
flush to avoid that.
https://bugzilla.gnome.org/show_bug.cgi?id=641411
Some people are trying to write code that calls g_application_register()
then checks to see if we became the primary name owner before exporting
objects. This sort of approach worked with libdbus-1 because method
calls to the freshly-acquired name would not be dispatched until the
application returned to the mainloop. With GDBus, however, dispatches
can occur at any time (including in the brief space between acquiring
the name and actually registering the object).
Add documentation to make it clear that you should not expect this to
work.
The existing docs are a bit inconsistent in that they say to follow
the dbus convention, but then give an example that doesn't.
This commit changes things to be how Ryan says they should be.
There are now fallback functions in the Win32 portion of
g_app_info that were previously only available under UNIX,
so add them here so that they can be exported as well.
The symbols are as follows:
g_app_info_get_fallback_for_type
g_app_info_get_recommended_for_type
If code creates a GDesktopAppInfo via g_desktop_app_info_new_from_keyfile(),
we'd try to send a NULL pointer down into GVariant.
Since in this case we don't have a filename, just send the empty
string. In the future we should either:
1) Change panel to use g_desktop_app_info_new_from_filename(), and
take the hit of parsing the file twice.
2) Add a g_key_file_get_origin_filename()
3) Add g_desktop_app_info_new_from_keyfile_and_name()
https://bugzilla.gnome.org/show_bug.cgi?id=638838
Add missing properties in the GDummyTlsConnection class. Also add
namespaces to property enumerations to avoid conflicts between classes.
Reviewed-by: Dan Winship <danw@gnome.org>
This property is now a GList of GByteArray values. Each
GByteArray contains the raw DER DN of the certificate authority.
This is far more useful for looking up a certificate (with the
relevant issuer) than a string encoded DN.
https://bugzilla.gnome.org/show_bug.cgi?id=637262
A new GDesktopAppInfo specific function which provides more control
over launched processes. Intended basically only for use in GNOME
Shell, where we want:
*) To directly know the GPid for each launched program, without
having to listen to a DBus signal emitted in our own process
*) Possibly control over the process environment; for example,
we may want to call setsid() or redirect file descriptors.
And in the future:
*) To avoid recursively calling ourself via DBus, when a later
patch causes g_app_info_launch() to indirect via the shell.
https://bugzilla.gnome.org/show_bug.cgi?id=606960
This signal contains the full path of the .desktop file, along with
the process id, which allows multiple interested components (like
GNOME Shell) to better know the state of the system (which processes
correspond to which .desktop files).
https://bugzilla.gnome.org/show_bug.cgi?id=606960
We want to be compatible with the following situation:
- there's no explicit default set in mimeapps.list
- we add support for a content type to a specific application, and that
list is empty
- the default should be picked from the system list, not overridden by
the user-added application.
So we make the default explicit in this case, by adding it to the
relevant section in mimeapps.list.
https://bugzilla.gnome.org/show_bug.cgi?id=637675
This commit also changes (maintaining compatibility) the way
user-specified default applications are stored (as in, those for which
g_app_info_set_as_default_for_type() has been called.
We now store the default application for a content type in a new group
in the mimeapps.list keyfile, and "Added Associations" tracks only the
applications that have been added by the user, following a
most-recently-used first order.
This is useful in GtkAppChooser-like widgets to pre-select the last used
application when constructing a widget.
https://bugzilla.gnome.org/show_bug.cgi?id=636311
Hiding the object/class structs in the source file makes this class not
subclassable.
Move them to the public header, and add a property for the icon, so that
subclasses can just use
g_object_new (DERIVED_TYPE,
"gicon", icon,
NULL);
to create an emblemed icon.
https://bugzilla.gnome.org/show_bug.cgi?id=636892
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>
An implementation of GSocketAddressEnumerator that handles proxy
enumeration. This class is mainly usefull for Connectables implementation
such as NetworkService, NetworkAddress and SocketAddress to handle proxies.
Reviewed-by: Dan Winship <danw@gnome.org>
Implement an extension point for proxy protocol implementation. This
is mainly useful for socket-based proxy where it is possible to use the
proxied socket the same way it would for other stream based socket.
Reviewed-by: Dan Winship <danw@gnome.org>
This method allow creating a network address from a URI. If no port is
found in the URI, the default_port parameter will be used. Note that new
property scheme is there for future TLS implementation.
Reviewed-by: Dan Winship <danw@gnome.org>
A GSocketInetAddress representing the proxy server address with additional
properties proxy type, destination address and port, username and password.
Reviewed-by: Dan Winship <danw@gnome.org>
This extension point allow extending GLib with library like LibProxy that
interprets system proxy settings and finds the appropriate configuration
based on the type of connection being made.
Reviewed-by: Dan Winship <danw@gnome.org>
This is really what (API) users expect from GDBusProxy - in
particular, mclasen and I ran into this problem while debugging a
upower issue, see
https://bugzilla.redhat.com/show_bug.cgi?id=624125
In a nutshell, the problem is that polkitd crashes while upower holds
a PolkitAuthority object (which in turns contains a GDBusProxy for the
well-known name org.freedesktop.PolicyKit1). This means that
subsequent calls on the PolkitAuthority (which is translated into
calls into the GDBusProxy) fails since :g-name-owner is NULL.
With this fix, we'll be requesting the bus daemon to launch polkitd
since we will start calling into org.freedesktop.PolicyKit1 as soon as
we notice that there is no owner for this name.
Unfortunately our test suite doesn't cover service activation so there
is no way to reliably test this. I will file a bug about this.
Signed-off-by: David Zeuthen <davidz@redhat.com>
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.
==26538== 145 (24 direct, 121 indirect) bytes in 1 blocks are definitely lost in loss record 765 of 790
==26538== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==26538== by 0x405233C: g_malloc (gmem.c:134)
==26538== by 0x406A57E: g_slice_alloc (gslice.c:836)
==26538== by 0x406A60C: g_slice_copy (gslice.c:858)
==26538== by 0x4035C5A: g_error_copy (gerror.c:160)
==26538== by 0x41B6387: g_simple_async_result_set_from_error (gsimpleasyncresult.c:638)
==26538== by 0x41FCDEB: g_dbus_connection_call_done (gdbusconnection.c:4808)
==26538== by 0x41B682E: g_simple_async_result_complete (gsimpleasyncresult.c:762)
==26538== by 0x41B686A: complete_in_idle_cb (gsimpleasyncresult.c:772)
==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 0x804B5CC: test_connection_send (gdbus-connection.c:407)
==26538== by 0x4073D04: test_case_run (gtestutils.c:1174)
Bug #627187.
==25403== 49 (24 direct, 25 indirect) bytes in 1 blocks are definitely lost in loss record 603 of 787
==25403== at 0x4005BDC: malloc (vg_replace_malloc.c:195)
==25403== by 0x405233C: g_malloc (gmem.c:134)
==25403== by 0x406A57E: g_slice_alloc (gslice.c:836)
==25403== by 0x406A5C3: g_slice_alloc0 (gslice.c:848)
==25403== by 0x4035B4E: g_error_new_literal (gerror.c:117)
==25403== by 0x4035ED9: g_set_error_literal (gerror.c:314)
==25403== by 0x41F6434: g_dbus_connection_close_sync (gdbusconnection.c:1284)
==25403== by 0x804A861: test_connection_life_cycle (gdbus-connection.c:158)
==25403== by 0x4073D04: test_case_run (gtestutils.c:1174)
==25403== by 0x4073FC2: g_test_run_suite_internal (gtestutils.c:1223)
==25403== by 0x4074077: g_test_run_suite_internal (gtestutils.c:1233)
==25403== by 0x4074077: g_test_run_suite_internal (gtestutils.c:1233)
==25403== by 0x40741FB: g_test_run_suite (gtestutils.c:1274)
==25403== by 0x40733E5: g_test_run (gtestutils.c:877)
==25403== by 0x804DC92: main (gdbus-connection.c:1024)
Bug #627187.
Add GZlibCompressor:file-info property. If it contains a non-NULL
GFileInfo, and the compressor is in GZIP mode, the filename and
modification time from the file info are written to the GZIP header
in the output data.
Add GZlibDeompressor:file-info property. If the decompressor is in GZIP
mode, and the GZIP data contains a GZIP header, the filename and
modification time are read from it, stored in a GFileInfo, and the
file-info property is notified.
Bug #617691.
This patch guarantees that g_output_stream_write() can never fail with
G_IO_ERROR_WOULD_BLOCK. Without such a guarantee, we would need some
kind of GIOPollable interface or some way to get an event when the
stream is writable again. Which is mostly useless considering that
this method is asynchronous anyway.
Note: this patch just codifies existing behavior - GUnixOutputStream,
GSocketOutputStream and other implementations already work this way.
See also bug 626748 comment 5 for how the GDBus code relies on this
guarantee.
https://bugzilla.gnome.org/show_bug.cgi?id=627071
Signed-off-by: David Zeuthen <davidz@redhat.com>
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>
This patch fixes this problem
Syscall param socketcall.sendmsg(msg.msg_control) points to uninitialised byte(s)
at 0x3D5B00EA60: __sendmsg_nocancel (syscall-template.S:82)
by 0x53F9790: g_socket_send_message (gsocket.c:2918)
by 0x540FDD0: g_unix_connection_send_credentials (gunixconnection.c:351)
by 0x542B93F: _g_dbus_auth_run_client (gdbusauth.c:618)
by 0x5438001: initable_init (gdbusconnection.c:2191)
by 0x53E09CC: g_initable_init (ginitable.c:105)
by 0x543F6E9: g_bus_get_sync (gdbusconnection.c:6091)
by 0x402C7E: test_connection_life_cycle (gdbus-connection.c:126)
by 0x4C7CABB: test_case_run (gtestutils.c:1174)
by 0x4C7CD84: g_test_run_suite_internal (gtestutils.c:1223)
by 0x4C7CE49: g_test_run_suite_internal (gtestutils.c:1233)
by 0x4C7CE49: g_test_run_suite_internal (gtestutils.c:1233)
Address 0x7fefff9fc is on thread 1's stack
Signed-off-by: David Zeuthen <davidz@redhat.com>
Previously if a GSocketConnection had a blocking GSocket, it would
sometimes block during asynchonous I/O, and if it had a non-blocking
socket, it would sometimes return G_IO_ERROR_WOULD_BLOCK from
synchronous I/O. This fixes the connection to not depend on the socket
state.
https://bugzilla.gnome.org/show_bug.cgi?id=616458
g_socket_client_connect_async() was always leaking its GCancellable,
and would also leak any GSocket that eventually failed to connect
after returning G_IO_ERROR_PENDING.
GSocket has a timeout flag now, but when using GSocketClient there was
no way to set the timeout until after connecting (or failing). Fix
that by adding a timeout property to GSocketClient.
Because g_simple_async_report_[g]error_in_idle() don't take a source tag
parameter, code that uses them can't currently use
g_simple_async_result_is_valid() (at least, not for the error case).
Bug 602417
