We previously waited 0.25s, which should be enough even on slow machines,
but you never know; but we also now wait in 0.1s increments, so this test
should actually be faster now.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=724113
Acked-by: Matthias Clasen <mclasen@redhat.com>
I searched all files that mention g_test_run, and replaced most
g_print() calls. This avoids interfering with TAP. Exceptions:
* gio/tests/network-monitor: a manual mode that is run by
"./network-monitor --watch" is unaffected
* glib/gtester.c: not a test
* glib/gtestutils.c: not a test
* glib/tests/logging.c: specifically exercising g_print()
* glib/tests/markup-parse.c: a manual mode that is run by
"./markup-parse --cdata-as-text" is unaffected
* glib/tests/testing.c: specifically exercising capture of stdout
in subprocesses
* glib/tests/utils.c: captures a subprocess's stdout
* glib/tests/testglib.c: exercises an assertion failure in g_print()
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=725981
Reviewed-by: Colin Walters <walters@verbum.org>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This stops it from interfering with structured stdout such as TAP.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=725981
Reviewed-by: Colin Walters <walters@verbum.org>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
This avoids any possibility of interfering with test syntax (such as
TAP) on stdout. TAP specifically does not parse stderr.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=725981
Reviewed-by: Colin Walters <walters@verbum.org>
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
When running the nonce-tcp and tcp-anonymous tests in one run
of gdbus-peer, or running one of them twice via command-line options
"-p /gdbus/tcp-anonymous -p /gdbus/tcp-anonymous", the one run second
would sometimes fail to connect with ECONNRESET.
Adding more debug messages revealed that in the successful case,
g_main_loop_run() was executed in the server thread first:
# tcp-anonymous: server thread: listening on tcp:host=localhost,port=53517
# tcp-anonymous: server thread: starting server...
# tcp-anonymous: server thread: creating main loop...
# tcp-anonymous: server thread: running main loop...
# tcp-anonymous: main thread: trying tcp:host=localhost,port=53517...
# tcp-anonymous: main thread: waiting for server thread...
but in the failing case, the main thread attempted to connect
before the call to g_main_loop_run() in the server thread:
# tcp-anonymous: server thread: listening on tcp:host=localhost,port=40659
# tcp-anonymous: server thread: starting server...
# tcp-anonymous: server thread: creating main loop...
# tcp-anonymous: main thread: trying tcp:host=localhost,port=40659...
# tcp-anonymous: server thread: running main loop...
(The log message "creating main loop" was immediately before
create_service_loop(), and "running main loop" was immediately
before g_main_loop_run().)
To ensure that the GDBusServer has a chance to start accepting
connections before the main thread tries to connect to it, do not
tell the main thread about the service_loop immediately, but instead
defer it to an idle.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=749079
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Philip Withnall <philip.withnall@collabora.co.uk>
This test originally did not connect to the bus, which meant it was
omitted from commits like 415a8d81 that made sure none of GLib tests
rely on the presence of an existing session bus. (In particular,
Debian autobuilders don't have a session bus.)
When test_double_array() was added, environments like the Debian
autobuilders didn't catch the fact that this test relied on having a
session bus, because it is often skipped in minimal environments
due to its libdbus-1 dependency.
We don't actually need to connect to a dbus-daemon here: it's enough
to convert the message from GVariant to D-Bus serialization, and
back into an in-memory representation through libdbus. That's what
check_serialization() does, and I've verified that when I re-introduce
bug #732754 by reverting commits 627b49b and 2268628 locally, this
test still fails.
Bug: https://bugzilla.gnome.org/show_bug.cgi?id=744895
Signed-off-by: Simon McVittie <simon.mcvittie@collabora.co.uk>
Reviewed-by: Colin Walters <walters@verbum.org>
The changed variable was previously uninitialised in the path where the
rate limit was actually changed. This could result in the
GObject::notify signal not getting emitted.
Spotted by Coverity.
CID: #1296516https://bugzilla.gnome.org/show_bug.cgi?id=748834
The third parameter of the thumnail_verify() function had been updated to
const GLocalFileStat, so update the thumbnail-verification test likewise
so that the test works properly on all supported platforms.
https://bugzilla.gnome.org/show_bug.cgi?id=711547
Always run the full algorithm for a given mime type before considering
fallback types.
This includes considering installed applications capable of handling a
particular mimetype, even if such an app is not explicitly marked as
default, and there is a default app for a less-specific type.
Specifically, this often helps with cases of installing apps that can
handle a particular subtype of text/plain. We want to take those apps
in preference to a generic text editor, even if that editor is listed as
the default for text/plain and there is no default listed for the more
specific type.
Because of the more holistic approach taken by the algorithm, it is now
more complicated, but it also means that we can do more work while
holding the lock. In turn, that lets us avoid duplicating some strings,
which is nice.
https://bugzilla.gnome.org/show_bug.cgi?id=744282
If g_dbus_message_to_blob() fails at all, it will leak its mbuf. Spotted
by running the gdbus-serialization test under Valgrind — so there is a
justification for leak-free tests after all!
In path_rule_matches(), the given paths may be of 0-length. Do not
access memory before the array in those case. This is for example
triggered by:
test_match_rule (con, G_DBUS_SIGNAL_FLAGS_MATCH_ARG0_PATH, "/", "", FALSE);
in test_connection_signal_match_rules().
This bug was found thanks to GCC AddressSanitizer.
https://bugzilla.gnome.org/show_bug.cgi?id=745745
Passing an nonsense string for the --dest argument can lead
to a segfault of gdbus. Thats not nice, so use our existing
validation function for bus names here.
https://bugzilla.gnome.org/show_bug.cgi?id=747541
Make sure error handling on repeated <summary> and <description> is
being done properly, not resulting in glib-compile-schemas throwing a
critical.
https://bugzilla.gnome.org/show_bug.cgi?id=747542
Fix a couple of issues in error handling in glib-compile-schemas.
The first problem is that, in case of repeated <summary> or
<description> tags we were still allocating a GString which was never
being freed (due to the throwing of the error resulting in immediate
termination of the parse).
The second problem is that if the repeated <summary> tag also had
attributes, we would attempt to set the GError twice.
https://bugzilla.gnome.org/show_bug.cgi?id=747542
Bug 747209 introduced an error when multiple <summary> or <description>
tags are found for a single key in a GSettings schema. This check
should have been present from the start, but it was left out because the
schema compiler doesn't include these items in the cache file. Even
still -- part of the schema compiler's job is validation, and it should
be enforcing proper syntax here.
Repeated <summary> and <description> tags are a semi-common problem when
intltool has been misconfigured in the build system of a package, but
it's possible to imagine mistakes being made by hand as well.
The idea is that these problems would be caught during the build of a
package and maintainers would be forced to fix their build systems.
An unintended side-effect of this change, however, is that the schema
compiler started ignoring already-installed schemas that contained these
problems, when rebuilding the cache. This means that the installation
of _any_ application would cause the regeneration of the entire cache,
with these already-installed applications being excluded. Without the
schema in the cache, the application would crash on next startup.
The validation check in the gsettings m4 macro passes --strict to the
compiler, which is not used when rebuilding the cache after
installation. Pass this flag down into the parser and only throw the
error in case --strict was given. This will result in the (desired)
build failure without also causing already-installed apps to stop
functioning.
This means that we will not get even a warning about the invalid schema
file in the already-installed case, but that's fine. There is no sense
spamming the user with these messages when they are already quite fatal
for the developer at build time.
https://bugzilla.gnome.org/show_bug.cgi?id=747472
Commit f10b655 removed the inclusion of gasyncresult.h from gdbusproxy.c,
but gdbusproxy.c uses g_async_result_get_source_object(), which caused a
build warning/error. Fix that.
The gdbus GTask port introduced a deadlock because some code had been
using g_simple_async_result_complete_in_idle() to ensure that the
callback didn't run until after a mutex was unlocked, but in the gtask
version, the callback was being run immediately. Fix it to drop the
mutex before calling g_task_return*(). Also, tweak
tests/gdbus-connection to test this.
https://bugzilla.gnome.org/show_bug.cgi?id=747349
Add support for copying session data between client connections.
This is needed for implementing FTP over SSL. Most servers use a separate
session for each control connection and enforce sharing of each control
connection's session between the related data connection.
Copying session data between two connections is needed for two reasons:
1) The data connection runs on a separate port and so has a different
server_identity which means it would not normally share the session with
the control connection using the session caching currently implemented.
2) It is typical to have multiple control connections, each of which
uses a different session with the same server_identity, so only one of
these sessions gets stored in the cache. If a data connection is opened,
(ignoring the port issue) it may try and reuse the wrong control
connection's session, and fail.
This operation is conceptually the same as OpenSSL's SSL_copy_session_id
operation.
https://bugzilla.gnome.org/show_bug.cgi?id=745255
This allows the caller to know when a socket has been bound so that
it can for instance set the SO_SENDBUF and SO_RECVBUF socket options
before listen is called
https://bugzilla.gnome.org/show_bug.cgi?id=738207
GTask used a 10-thread thread pool for g_task_run_in_thread() /
g_task_run_in_thread_sync(), but this ran into problems when task
threads blocked waiting for another g_task_run_in_thread_sync()
operation to complete. Previously there was a workaround for this, by
bumping up the thread limit when that case was detected, but deadlocks
could still happen if there were non-GTask threads involved. (Eg, task
A sends a message to thread X and waits for a response, but thread X
needs to complete task B in a thread before returning the response to
task A.)
So, allow GTask's thread pool to be expanded dynamically, by watching
it from the glib worker thread, and growing it (at an
exponentially-decreasing rate) if too much time passes without any
tasks completing. This should solve the deadlocking problems without
causing sudden breakage in apps that assume they can queue huge
numbers of tasks at once without consequences.
https://bugzilla.gnome.org/show_bug.cgi?id=687223
This schema compiler was completely ignoring <summary> and
<description> tags. Unfortunately, there are modules out there
who merge translations for these back in, with xml:lang. And
this is giving dconf-editor a hard time. Since this is not
how translations of schemas are meant to be done, just
reject such schema files.
Also add tests exercising the new error handling.
https://bugzilla.gnome.org/show_bug.cgi?id=747209
glib-compile-resources was guessing a filename ending
in .c when generating sources, but did not do the same
for headers. Fix it so it generates a .h file when
guessing the filename for headers.
https://bugzilla.gnome.org/show_bug.cgi?id=746753
The hash table stores the list of unmatched IN_MOVE_FROM events, but we
were removing entries from it when popping IN_MOVE_TO events.
Fix that up to correct a crash in nautilus due to the assertion failure
below.
https://bugzilla.gnome.org/show_bug.cgi?id=746749
Due to a typo, a rename reported via a pair of delete/create events (due
to the watcher not giving the flag for moves to be paired) was
accidentally reported as being created with the old name instead of the
new name.
Fix that.
We declare the typedefs for GListModel and GListStore in giotypes.h, as
a matter of convention. This is not actually required, since the
typedef is emitted as part of the G_DECLARE_* macros.
The giotypes.h approach is only used to avoid cyclic dependencies
between headers, which is not a problem in this case.
Type redefinition is a C11 feature, and although it was around in some
compilers before then, gcc 4.2.1 (from 2007) is apparently still in wide
use, being the default compiler for OpenBSD.
Eventually, we will probably hit a case where we actually need to
redefine a type, but since we're not there yet, let's back off a bit.
This WIP patch moves the Windows Directory Monitoring code to the new
GLocalFileMonitor mechanism, and adds file monitoring in the process.
Progress from previous patch:
-File renames are now properly supported, but G_FILE_MONITOR_EVENT_MOVED_IN
and G_FILE_MONITOR_EVENT_MOVED_OUT needs to be investigated, as
ReadDirectoryChangesW() seems to send FILE_ACTION_REMOVED when a file is
moved out of a directory.
-Events are handled for both the long and short (8.3) variants of the
filenames, and files monitored will report changes when it is changed
via its short or long filenames.
Things to be done:
-Perhaps find out about attribute changes in files in a monitored
directory; if a file is monitored, attribute changes are correctly
handled.
-Investigate on G_FILE_MONITOR_EVENT_MOVED_OUT,
G_FILE_MONITOR_EVENT_MOVED_IN, G_FILE_MONITOR_EVENT_PRE_UNMOUNT,
G_FILE_MONITOR_EVENT_UNMOUNTED.
-Investigate on the "boredom" algoritm, and see how we can do it on
Windows.
https://bugzilla.gnome.org/show_bug.cgi?id=730116
Completely rewrite the FAM file monitor. Major changes:
- now runs in the worker thread
- dispatches events in a threadsafe way via GFileMonitorSource
- uses unix fd source instead of a GIOChannel
- is now simple enough to fit into one short file
This is the bare minimal effort. This seems not to crash immediately,
but it definitely needs some better testing.
The backend is not in good shape. It could use some serious work.
Use the "interesting" value from g_file_monitor_source_handle_event() to
decide if we're currently being flooded by a stream of boring events.
The main case here is when one or more files is being written to and the
change events are all being rate-limited in the GFileMonitor frontends.
In that case, we become "bored" with the event stream and add a backoff
timeout. In the case that it is exactly one large file being written
(which is the common case) then leaving the event in the queue also lets
the kernel perform merging on it, so when we wake up, we will only see
the one event. Even in the case that the kernel is unable to perform
merging, the context switch overhead will be vastly reduced.
In testing, this cuts down on the number of wake ups during a large file
copy, by a couple orders of magnitude (ie: less than 1% of the number of
wake ups).
Return an "interesting" boolean from the event handler function on
GFileMonitorSource.
An event was "interesting" if it will result in a signal actually being
dispatched to the user. It is "uninteresting" if it only hit an
already-dirty rate limiter.
We will use this information to do some backing off in the backends when
faced with a flood of uninteresting events.
We generally assume that an IN_CREATE event is the start of a series of
events in which another process is doing this:
fd = creat (...) -> IN_CREATE
write (fd, ..) -> IN_MODIFY
write (fd, ..) -> IN_MODIFY
close (fd) -> IN_CLOSE_WRITE
and as such, we use the CHANGES_DONE_HINT event after CREATED in order
to show when this sequence of events has completed (ie: when we receive
IN_CLOSE_WRITE when the user closes the file).
Renaming a file into place is handled by IN_MOVED_FROM so we don't have
to worry about that.
There are many other cases, however, where a new file 'appears' in a
directory in its completed form already, and the kernel reports
IN_CREATE. Examples include mkdir, mknod, and the creation of
hardlinks. In these cases, there is no corresponding IN_CLOSE_WRITE
event and the CHANGES_DONE_HINT will have to be emitted by an arbitrary
timeout.
Try to detect some of these cases and report CHANGES_DONE_HINT
immediately.
This is not perfect. There are some cases that will not be reliably
detected. An example is if the user makes a hardlink and then
immediately deletes the original (before we can stat the new file).
Another example is if the user creates a file with O_TMPFILE. In both
of these cases, CHANGES_DONE_HINT will still eventually be delivered via
the timeout.
Remove all event merging and dispatch logic from GFileMonitor. The only
implementation of GFileMonitor outside of glib is in gvfs and it already
does these things properly.
Get rid of GLocalDirectoryMonitor. We will use a single class,
GLocalFileMonitor, for both directory and file monitoring. This will
prevent every single backend from having to create two objects
separately (eg: ginotifydirectorymonitor.c and ginotifyfilemonitor.c).
Introduce GFileMonitorSource as a thread-safe cross-context dispatch
mechanism. Put it in GLocalFileMonitor. All backends will be expected
to dispatch via the source and not touch the GFileMonitor object at all
from the worker thread.
Remove all construct properties from GLocalFileMonitor and remove the
"context" construct property from GFileMonitor. All backends must now
get the information about what file to monitor from the ->start() call
which is mandatory to implement.
Remove the implementation of rate limiting in GFileMonitor and add an
implementation in GLocalFileMonitor. gvfs never did anything with this
anyway, but if it wanted to, it would have to implement it for itself.
This was done in order to get the rate_limit field into the
GFileMonitorSource so that it could be safely accessed from the worker
thread.
Expose g_local_file_is_remote() internally for NFS detection.
With the "is_remote" functionality exposed, we can now move all
functions for creating local file monitors to a proper location in
glocalfilemonitor.c
Port the inotify backend to adjust to the changes above. None of the
other backends are ported yet. Those will come in future commits.
Remove the hardwired 1 second event queue logic from inotify-kernel and
replace it with something vastly less complicated.
Events are now reported as soon as is possible instead of after a
delay.
We still must delay IN_MOVED_FROM events in order to look for the
matching IN_MOVED_TO events, and since we want to report events in order
this means that events behind those events can also be delayed. We
limit ourselves, however:
- no more than 100 events can be delayed at a time
- no event can be delayed by more than 10ms
https://bugzilla.gnome.org/show_bug.cgi?id=627285
Add a new internal constructor for GLocalFile (which itself is private).
This new constructor allows creating a GLocalFile from a dirname and a
basename, assuming that the dirname is already in canonical form and the
basename is a regular basename.
This will be used for creating GLocalFile instances from the file
monitoring code (for signal emissions).
For all of the effort spent ensuring that this algorithm would be
correctly threadsafe, I messed up the order of operations within a
single thread when porting to the new approach.
Fix that up.
Also: fix some overzealous asserting in the testcases. Since shutdown
is now lazy, we can never surely say !is_running at any particular point
in time.
This can be used to query whether the task has completed, in the sense
that it has had a result set on it, and has already – or will soon –
invoke its callback function.
Notifications for this property are emitted immediately after the task’s
main callback, in the same main context as that callback. This allows
for multiple bits of code to listen for completion of the GTask, which
opens the door for blocking on cancellation of the GTask and improved
handling of ‘pending’ behaviour.
https://bugzilla.gnome.org/show_bug.cgi?id=743636
g_socket_client_add_application_proxy() claimed "When the indicated
proxy protocol is returned by the #GProxyResolver, #GSocketClient will
consider this protocol as supported but will not try to find a #GProxy
instance to handle handshaking." But in fact, it did the checks in the
wrong order, so GProxy proxies ended up overriding
application-specified ones. Fix that.
Also, simplify the code a bit by making use of g_hash_table_add() and
g_hash_table_contains().
https://bugzilla.gnome.org/show_bug.cgi?id=733876
Currently, the Windows code use Winsock2-specific APIs to try to emulate
calls such as inet_pton(), inet_ntop() and if_nametoindex(), which may not
do the job all the time. On Vista and later, Winsock2 does provide a
proper implementation for these functions, so we can use them if they exist
on the system, by querying for them during g_networking_init(). Otherwise,
we continue to use the original code path for these, in the case of XP and
Server 2003.
This enables many of the network-address tests to pass on Windows as a
result, when the native Winsock2 implementations can be used.
https://bugzilla.gnome.org/show_bug.cgi?id=730352
Check the IPv6 addresses on Windows, as we need to reject those that have
brackets/ports around them as valid addresses in this form would have been
accepted during the call to g_inet_address_new_from_string ().
https://bugzilla.gnome.org/show_bug.cgi?id=730352
There was a theoretical deadlock between the worker trying to emit a
signal at the same time as we were waiting for it to shutdown the
notification (while holding the lock).
The deadlock was particularly annoying because we didn't really need to
wait for the shutdown and because it wasn't possible to signals to
arrive while waiting for a start. Attempting to deal with start and
stop in an asymmetric way could have lead to other weird situations,
however.
Drop the lock while waiting for the worker thread to start. This means
that we face the possibility of multiple waiters on the cond at the same
time, so we need to make more of a state machine.
https://bugzilla.gnome.org/show_bug.cgi?id=742599
GUnixMountMonitor was not threadsafe before. It was a global singleton
which emitted signals in the first thread that happened to construct it.
Move it to a per-context singleton model where each GMainContext gets
its own GUnixMountMonitor. Monitor for the changes from the GLib worker
thread and dispatch the results to each context with an active monitor.
https://bugzilla.gnome.org/show_bug.cgi?id=742599
Deprecate g_unix_mount_monitor_set_rate_limit() and turn it into a
no-op.
This function doesn't behave as advertised. It only controls rate
limiting for filesystem-based monitors. It has no impact over reporting
mount changes on Linux, for example, because those are based on polling
for changes in /proc (which doesn't use filesystem monitors). It also
has no impact on Mac OS because a library interface is used there.
This was added in https://bugzilla.gnome.org/show_bug.cgi?id=521946 in
order to be used by HAL, which is effectively dead. udisks no longer
uses this code at all.
https://bugzilla.gnome.org/show_bug.cgi?id=742599
This is a singleton, but we have a function called _new() to get it.
What's worse is that the documentation makes no mention of this, and
actually specifically says that a new monitor will be created each time.
https://bugzilla.gnome.org/show_bug.cgi?id=742599
Add a new internal helper called GContextSpecificGroup.
This is a mechanism for helping to maintain a group of context-specific
monitor objects (eg: GAppInfoMonitor, GUnixMountMonitor).
https://bugzilla.gnome.org/show_bug.cgi?id=742599
If someone explicitly calls g_application_quit() then don't attempt to
drain the mainloop of remaining sources.
This allows applications with 100% CPU utilisation to quit reliably.
https://bugzilla.gnome.org/show_bug.cgi?id=744876
We install win32-software/autorun.exe (as test data for mime scanning)
only on UNIX builds, so don't attempt to chmod it on 'make install'
unless we're on UNIX.
I love Emacs keyboard macros, used them to convert the list of
defines cleverly into a list of tests, then iterated and filled in
the necessary constructor arguments.
After ::shutdown, run the mainloop until all pending activity is
handled, before returning from run().
Among other things, this gives a chance for destroyed windows to be
properly withdrawn from the windowing system.
https://bugzilla.gnome.org/show_bug.cgi?id=744876
This is *significantly* more pleasant to use from C (while handling
errors and memory cleanup).
While we're here, change some ugly, leaky code in
tests/desktop-app-info.c to use it, in addition to a test case
in tests/file.c.
https://bugzilla.gnome.org/show_bug.cgi?id=661554
g_application_bind_busy_property() had the restriction that only one
property can be bound per object, so that NULL could be used to unbind.
Even though this is enough for most uses, it is a weird API.
Lift that restriction and add an explicit unbind function.
https://bugzilla.gnome.org/show_bug.cgi?id=744565
Add an implementation of non-thread-emulated async close of a GIOStream
if either of the underlying stream objects support it.
This prevents us from calling close() functions from another thread on
an object that may not be expecting that. It also allows us to skip the
thread entirely in case our objects support a pure async close.
https://bugzilla.gnome.org/show_bug.cgi?id=741630
Add an internal helper to find out if close_async() is implemented via
threads using the default implementation in the base class.
We will use this to decide if we should do a 'pure async' close of a
GIOStream or not.
https://bugzilla.gnome.org/show_bug.cgi?id=741630
delayed_close_free() calls g_object_unref() on a variable that is
expected to possibly contain NULL (as indicated by the fact that the
NULL case is handled in my_slow_close_output_stream_close_async()).
This is dead code right now (due to a bug in GDBus), which is why it
isn't actually causing a failure. It should still be fixed, however.
https://bugzilla.gnome.org/show_bug.cgi?id=743990
GApplication set the prgname to the application's id when it was running
in service mode. This broke with the addition of new --app-id option,
because g_set_prgname() was called before parsing the options. Calling
it after option parsing doesn't work, because GOptionContext sets
prgname to argv[0] unconditionally.
Instead of changing the semantics of GOptionContext, simply remove this
functionality from GApplication. It is very unusual to have the prgname
set to the app id instead of the binary's name and might confuse people
when looking at logs etc.
When overriding local_command_line() from a subclass,
g_option_context_parse() might never be invokded. Thus, continue setting
the prgname to argv[0] in GApplication.
https://bugzilla.gnome.org/show_bug.cgi?id=743933
Balancing g_application_{un,}mark_busy() is non-trivial in some cases.
Make it a bit more convenient by allowing to bind multiple boolean
properties (from different objects) to the busy state. As long as these
properties are true, the application is marked as busy.
https://bugzilla.gnome.org/show_bug.cgi?id=744565
Add g_list_store_insert_sorted() which takes a GCompareDataFunc to
decide where to insert. This ends up being a very trivial function,
thanks to GSequence.
https://bugzilla.gnome.org/show_bug.cgi?id=743927
Make sure that we only match the _get_type() function name by
restricting the regexp to matching [A-Za-z0-9_]. We were matching on .*
before which means that if we had two _get_type() functions appearing on
a single line then we would get everything in between them included (by
the default rule of '*' being greedy).
This affected G_DECLARE_*_TYPE which puts several uses of _get_type()
into a single line.
GListModel is an interface that represents a dynamic list of GObjects.
Also add GListStore, a simple implementation of GListModel that stores
all objects in memory, using a GSequence.
https://bugzilla.gnome.org/show_bug.cgi?id=729351
Currently the only way to set a state hint on an action is through a
subclass; add a g_simple_action_set_state_hint() method so that this
becomes easier for clients that already use GSimpleAction.
https://bugzilla.gnome.org/show_bug.cgi?id=743521
When implementing blocking operations on top of
nonblocking sockets we should always first try to
perform the operation and then if needed handle
EAGAIN and wait with g_socket_wait_condition.
This is an optimization since we avoid calling
wait condition when it is not needed, but most
importantly this fixes hangs on win32 where some
events (in particular FD_WRITE) are only emitted
after the operation fails with EWOULDBLOCK.
https://bugzilla.gnome.org/show_bug.cgi?id=732439https://bugzilla.gnome.org/show_bug.cgi?id=741707
Add a unit test that checks g_socket_new_from_fd by creating
a gsocket, obtaining its fd, duplicating the fd and then creating
a gsocket from the new fd. This shows a hang on win32 since the
gsocket created from the fd never receives the FD_WRITE event
because we wait for the condition without first trying to write
and windows signals the condition only after a EWOULDBLOCK error.
https://bugzilla.gnome.org/show_bug.cgi?id=741707
We were asking for properties on NM's dbus interface, but if NM is not
running then there won't be any. Check if the name has an owner before
doing anything to it.
https://bugzilla.gnome.org/show_bug.cgi?id=741653
In g_file_make_directory_with_parents(), the my_error variable is used
for several different purposes throughout the whole function, not all of
which are obvious. This explains the situation with some comments.
https://bugzilla.gnome.org/show_bug.cgi?id=719455
Allows sending of multiple messages (packets, datagrams)
in one go using sendmmsg(), thus drastically reducing the
number of syscalls when sending out a lot of data, or when
sending out the same data to multiple recipients.
https://bugzilla.gnome.org/show_bug.cgi?id=719646
Fix two problems:
1) If g_socket_service_stop is called before the accept call is requeued,
then the reference count won't decrease and this code will hang forever:
while (G_OBJECT (service)->ref_count == ref_count)
g_main_context_iteration (NULL, TRUE);
2) Sometimes the testcase fails (maybe 1 in 200 times for me):
GLib-GIO:ERROR:socket-listener.c:73:connection_cb: assertion failed
(G_OBJECT (service)->ref_count == 2): (3 == 2)
Aborted (core dumped)
The problem is that depending on ordering, cancellation of the async
listener can require further main context iterations before it releases
the reference on the socket service. Furthermore, in some cases, it
requires at least one iteration.
https://bugzilla.gnome.org/show_bug.cgi?id=712570
Add a property to GNetworkMonitor indicating the level of network
connectivity: none/local, limited, stuck behind a portal, or full.
The default implementation just returns none or full depending on the
value of is-available.
https://bugzilla.gnome.org/show_bug.cgi?id=664562
Add G_IO_ERROR_CONNECTION_CLOSED as an alias for
G_IO_ERROR_BROKEN_PIPE, and also return it on ECONNRESET.
It doesn't really make sense to try to distinguish EPIPE and
ECONNRESET at the GLib level, since the exact choice of which error
gets returned in what conditions depends on the OS. Given that, we
ought to map the two errors to the same value, and since we're already
mapping EPIPE to G_IO_ERROR_BROKEN_PIPE, we need to map ECONNRESET to
that too. But the existing name doesn't really make sense for sockets,
so we add a new name.
https://bugzilla.gnome.org/show_bug.cgi?id=728928
This is a convenience method for creating a GNetworkAddress which is
guaranteed to return IPv4 and IPv6 loopback addresses. The program
cannot guarantee that 'localhost' will resolve to both types of
address, so programs which wish to connect to a local service over
either IPv4 or IPv6 must currently manually create an IPv4 and another
IPv6 socket, and detect which of the two are working. This new API
allows the existing GSocketConnectable machinery to be used to
automate that.
Based on a patch from Philip Withnall.
https://bugzilla.gnome.org/show_bug.cgi?id=732317
g_settings_has_signal_handlers() checks whether any of the signals has
pending handlers. However, g_signal_has_handler_pending() matches on
exact detail, even when passing 0. Subscribing to one of GSettings'
signals with a detail will fail this check and never connect to the
backend.
Fix this by calling has_handler_pending() with the key as detail as
well.
https://bugzilla.gnome.org/show_bug.cgi?id=740848
Add a GSocketListener test program. Currently the only test is a
regression test for bug 712570 (based on a standalone bug reproducer
provided by Ross Lagerwall).
If all users of a GThreadedSocketService release their references to the
service while a connection thread is running, the thread function will
release the last reference to the service which causes the finalize to
deadlock waiting for all threads to finish (because it's called from the
thread function).
To fix this, don't wait for all threads to finish in the service's
finalize method. Since the threads hold a reference to the service,
finalize should only be called when all threads are finished running (or
have unrefed the service and are about to finish).
https://bugzilla.gnome.org/show_bug.cgi?id=712570
If SSL 3.0 has been disabled (at the host, application, or library
level), then the "use-ssl3" property becomes a "fail-immediately"
property.
Despite the name, the point of the property wasn't really specifically
to use SSL 3.0; it was to allow fallback when talking to broken
servers that do SSL/TLS negotiation incorrectly and break when they
see unexpectedly-high version numbers. So if we can't fall back to SSL
3.0, then the "use-ssl3" property should fall back to TLS 1.0 instead
(since there are hosts that will reject a TLS 1.2 handshake, but
accept a TLS 1.0 one).
glib-networking is being updated to implement that behavior, so update
the documentation here.
https://bugzilla.gnome.org/show_bug.cgi?id=738633
In commit 8ff5668, we are subscribing the GSettings backend later, but this
meant that we need to initialize cache_lock earlier, as we might try to
use that lock before a change notification is issued to subscribe the
backend, which would then cause an access violation if we are trying to
read GSettings values, as that lock is used to access the Windows Registry.
Initialize cache_lock once we initialize the GSettings Registry backend,
and delete it upon finalize, so that g_settings_read_from_backend() can
proceed normally, even if the GSettings backend is not yet subscribed.
https://bugzilla.gnome.org/show_bug.cgi?id=740413
GSettings objects begin watching for changes as soon as they are created
in order that they can emit the "changed" signal.
In the case of dconf, if we want to be able to emit the changed signal,
we need to go on the bus and add some match rules. This requires
creating the dconf helper thread and also requires initialising GDBus
(which creates another thread).
Some users of GSettings are never interested in the "changed" signal.
One of these users is the glib-networking code that gets run every time
a new network connection is created.
Some users are reporting that they are annoyed that simply establishing
a network connection would spawn two extra threads and create a D-Bus
connection.
In order to avoid doing unnecessary work for these simple uses, delay
the subscription until we know that we will actually need to do it.
We do this in a simple way, using a simple argument: in order for the
user to care that a value changed then they must have:
1) watched for a change signal; and then
2) actually read a value
If the user didn't actually read a value then they cannot possibly be
interested in if the value changed or not (since they never knew the old
value to begin with and therefore would be unable to observe that it
ever changed, since they have nothing to compare the new value with).
This really is a behaviour change, however, and it does impact at least
one user: the 'monitor' functionality of the GSettings commandline tool,
which is interested in reporting changes without ever having known the
original values. We add a workaround to the commandline tool in order
to ensure that it continues to function properly.
It's also possible to argue that it is completely valid to have read a
value and _then_ established a change signal connection under the
(correct) assumption that it would not have been possible to miss a
change signal by virtue of not having returned to the mainloop.
Although this argument is true, this pattern is extremely non-idiomatic,
and the problem is easily avoided by doing things in the usual order.
We never really talked about change notification in the overview
documentation for GSettings, so it seems like now is a good time to add
some discussion, including the new rules for when one can expect change
signals to be emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=733791
This should already work according to the documentation, but doesn't
because main_options is consumed before the check in
g_application_parse_command_line().
Fix by moving the check for main_options up.
https://bugzilla.gnome.org/show_bug.cgi?id=740157
The win32 headers do:
#define interface struct
which is just evil and breaks other code that assumes it can use
"interface" as a variable name. gnetworking.h was supposed to be doing
"#undef interface" after including the win headers, but it did it too
soon, resulting in it getting redefined by a later include. Fix this.
https://bugzilla.gnome.org/show_bug.cgi?id=738551
g_tls_certificate_new_from_file() was only loading the complete chain
if it was fully valid, but we only meant to be validating that it
formed an actual chain (since the caller may be planning to ignore
other errors).
https://bugzilla.gnome.org/show_bug.cgi?id=729739
Fix a hang due to overflow by using unsigned numbers and explicitly
checking if the number overflows to zero. This also fixes the previous
logic which assigned an int which may be negative to an unsigned number
resulting in sign extension and strange results.
Use gsize rather than int to allow for large buffers on 64 bit machines.
https://bugzilla.gnome.org/show_bug.cgi?id=727988
Fix a hang due to overflow by using unsigned numbers and explicitly
checking if the number overflows to zero. This also fixes the previous
logic which assigned an int which may be negative to an unsigned number
resulting in sign extension and strange results.
Use gsize rather than int to allow for large streams on 64 bit machines.
https://bugzilla.gnome.org/show_bug.cgi?id=727988
There are two consistent interpretations that could be taken for memory
handling of the 'invocation' parameter passed to the method_call() virtual
function of GDBusInterfaceVTable
- A reference is passed (transfer full) to the method_call() virtual function,
and that reference is then passed (transfer full) to the return_value/error
functions on GDBusMethodInvocation.
- An internal reference is retained from the point where method_call() is called
until the return_value/error function is called.
Since the return_value/error functions were already marked (transfer full),
we use the first interpretation, annotate the invocation parameter of
method call as (transfer full) and describe this in the documentation, along
with the idea that you are always supposed to call one of the return_value/error
functions.
See bug 738122 for the leak this caused in GJS.
https://bugzilla.gnome.org/show_bug.cgi?id=738259
Clarify in the documentation that a GSource created with
g_cancellable_source_new() must be explicitly removed from its
GMainContext before the GCancellable can be finalised.
This could be a common way of leaking GCancellables.
https://bugzilla.gnome.org/show_bug.cgi?id=737259
da053e34 broke the tls-certificates test by requiring the backend to
implement g_tls_certificate_verify() (which the test TLS backend
didn't). Add a trivial implementation to make the test pass again;
we'll need something more complicated when we add tests that are
supposed to get errors.
So shortcut it.
I wrote this patch less as a performance optimization and more as a
clarification, so that people looking at the code can be assured of this
invariant.
https://bugzilla.gnome.org/show_bug.cgi?id=738374
These functions are inconsistent with our normal conventions in that
they set an output variable to a specified value, even in the case that
an error is thrown.
Document very clearly that this should be considered exceptional.
https://bugzilla.gnome.org/show_bug.cgi?id=737451
Similar to the previous patch, this commit contains a minor violation of
normal API conventions. See the explanation in the previous commit
message.
Heavily based on a patch from Ignacio Casal Quinteiro.
https://bugzilla.gnome.org/show_bug.cgi?id=737451
Add an asynchronous version of _read_all().
This API is not fully consistent with the normal expectations of a
non-asynchronous version. Consistency between the sync and async version is
probably more important.
The API will still bind correctly, but access to all functionality will
not be available: specifically, in the case of an error, higher level
languages will be unable to determine how many bytes were successfully
read before the error. Most users will probably not want to use this
information anyway, so this is OK -- and if they do need the
information, then they can just write the loop for themselves.
Heavily based on a patch from Ignacio Casal Quinteiro.
https://bugzilla.gnome.org/show_bug.cgi?id=737451
Commit e24e89b accidentally ironically introduced a typo when replacing
the code with symbolic contents. Specifically, "Added Associations" was
replaced with "Default Applications" when reading defaults.list, giving
a warning about the file containing a "Default Applications" group.
If this was intended, it should have not been lumped in with a cleanup.
This patch changes the behavior of the following functions:
g_tls_certificate_new_from_pem
g_tls_certificate_new_from_file
g_tls_certificate_new_from_files
If more than one certificate is found it will try to load the chain.
It is assumed that the chain will be in the right order (top-level
certificate will be the last one in the file). If the chain cannot be
verified, the first certificate in the file will be returned as before.
https://bugzilla.gnome.org/show_bug.cgi?id=729739
g_thread_pool_push() only returns an error if it fails to spawn a new
thread. However, it unconditionally adds the task to its worker queue,
so:
• if _any_ threads exist in the pool, the task will eventually be
handled; and
• if _no_ threads exist in the pool, the task will be handled if one
is eventually successfully spawned.
If no more threads are ever spawned, the process probably has bigger
problems than a single GTask which is taking forever to complete.
https://bugzilla.gnome.org/show_bug.cgi?id=736806
For the GPtrArray example, several variables declared on the same line
is harder to read and to work with (to move, remove or comment a single
variable declaration).
Some desktop file directories, like /usr/local/share/applications may be
missing on some systems.
When we try to inotify on these directories, this will result in a
every-4-seconds poll being setup which is quite bad.
This is an issue that should be fixed in inotify itself but the problem
is much larger there. For now, we can work around it in GDesktopAppInfo
by refusing to monitor missing directories.
We may get some spurious notifications of changes in the case that
/usr/local/share or /usr/local/share/applications is created without
actually adding desktop files, but spurious changes can already be
reported in other cases, so that's OK. We won't get (user-visible)
notification for a simple case of a completely unrelated file being
created (however we cannot avoid the wakeup in this case due to how
inotify works). That's probably pretty theoretical, though, since files
in /usr don't change much and for the home directory we're likely to
have at least ~/.config and ~/.local existing.
https://bugzilla.gnome.org/show_bug.cgi?id=736350
We use "tweaks" structures to track how a particular directory impacts
the list of added, removed and default applications. We maintain this
set of tweaks for each directory, in a hash table, keyed by unaliased
mime type name, in order to facilitate fast lookups.
A typo in the logic for creating and maintaining the uniqueness of these
structures was causing the default app to be selected incorrectly from
time to time. Fix that.
If a g_socket_client_connect_async() operation is cancelled between the
CONNECTING and CONNECTED events (i.e. while in the
g_socket_connection_connect_async() call), the code in
g_socket_client_connected_callback() would previously unconditionally
loop round and try the next socket address from the address enumerator
(by calling enumerator_next_async()). This would correctly handle the
cancellation and return from the overall task — but not before emitting
a spurious RESOLVING event.
Avoid emitting the spurious RESOLVING event by explicitly handling
cancellation at the beginning of g_socket_client_connected_callback().
https://bugzilla.gnome.org/show_bug.cgi?id=735179
This function adds a single main option entry to be handeled by
GApplication. The option entry has it arg_data field set to NULL
and will be added to the applications packed_options.
The rationale for this is that bindings will be able to add
command line options even when they can't use the un-boxed struct
GOptionEntry.
https://bugzilla.gnome.org/show_bug.cgi?id=727455
It turns out that this bug actually would (sometimes) impact any sort of
fixed-sized array with an alignment requirement of 8 due to incorrectly
counting the alignment inserted between the (aligned 4) array length and
the actual data.
Fix this properly and remove the exception for doubles.
https://bugzilla.gnome.org/show_bug.cgi?id=732754
