Commit Graph

24141 Commits

Author SHA1 Message Date
Philip Withnall
ef72bed1c0 gtask: Document dependency on GMainContext more explicitly
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Fixes: #2404
2021-09-24 07:57:49 +01:00
Марко Костић
8f2a61f35f Update Serbian translation 2021-09-24 02:11:00 +00:00
Emmanuel Fleury
f304df34c7 Coerce type cast to void* because it causes compiler warnings
glib/gtestutils.c:4261:11: warning: incompatible pointer types passing 'gpointer *' (aka 'void **') to parameter of type 'GSList **' (aka 'struct _GSList **')
  while (!g_atomic_pointer_compare_and_exchange (test_filename_free_list, node->next, node));
          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
glib/gatomic.h:215:44: note: expanded from macro 'g_atomic_pointer_compare_and_exchange'
    __atomic_compare_exchange_n ((atomic), &gapcae_oldval, (newval), FALSE, __ATOMIC_SEQ_CST, __ATOMIC_SEQ_CST) ? TRUE : FALSE; \
                                           ^~~~~~~~~~~~~~
2021-09-23 22:09:07 +02:00
Daniel Cheng
2f98cbe483 Remove function pointer casts when calling xdg_run_command_on_dirs().
The function pointer casts silence the compiler and allow the code to
build (and even run in the typical case). However, when building with
control flow integrity checks, the runtime (rightfully) complains about
calling a function via a mismatched function pointer type.
2021-09-23 21:56:21 +02:00
Philip Withnall
38869ece24 xdgmime: Prevent infinite loops from badly-formed MIME registrations
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Closes: #1875
2021-09-23 19:23:33 +02:00
Philip Withnall
fa6f45536d xdgmime: Add xdg_mime_set_dirs() method to override XDG envvars
In order to make xdgmime properly relocatable so that unit tests can use
it without it reading and modifying the user’s actual xdgmime files, and
without the need to call setenv() (and get tied up with thread safety
problems), add a xdg_mime_set_dirs() method to allow the dirs to be
overridden. They will still default to the values of $XDG_DATA_HOME and
$XDG_DATA_DIRS.

Signed-off-by: Philip Withnall <withnall@endlessm.com>
2021-09-23 19:23:33 +02:00
Sébastien Wilmet
b765c7950c gio/xdgmime/: LGPLv2+ -> LGPLv2.1+
https://bugzilla.gnome.org/show_bug.cgi?id=776504
2021-09-23 19:23:33 +02:00
Руслан Ижбулатов
e4d1813368 xdgmime: Finer handling for cases where mmap() is not available
Allocate an empty cache object, check cache objects for being empty
before using them.
Otherwise the code will re-read cache every 5 seconds, as NULL cache
does not trigger the code that stores mtime, which makes the cache
file appear modified/unloaded permanently.

https://bugzilla.gnome.org/show_bug.cgi?id=735696
2021-09-23 19:23:33 +02:00
Matthias Clasen
e7822bd303 Silence an uninitialize variable warning 2021-09-23 19:23:33 +02:00
Matthias Clasen
14e46ca288 Don't compile some unused functions in gio/xdgmime/ 2021-09-23 19:23:33 +02:00
Matthias Clasen
a1bfe899ab Don't give up too early when collecting mime types
Since returning exactly one match has special significance, don't
give up matching before we've found at least 2 types. Also, make
sure that we don't return the same mime type more than once.
Bug 541236.
2021-09-23 19:23:33 +02:00
Simon McVittie
d099ac6ceb Merge branch '2401-object-manager-warning' into 'main'
gdbusobjectmanagerclient: Don’t warn if removing an interface fails

Closes #2401

See merge request GNOME/glib!2263
2021-09-23 10:24:26 +00:00
Emmanuel Fleury
b4893986b0 Force to use the config.h header file (required for HAVE_MMAP macro) 2021-09-23 11:32:02 +02:00
Emmanuel Fleury
3d2ac608de Update gio/xdgmime with commit 722325f of xdgmime project 2021-09-23 11:32:02 +02:00
Philip Withnall
3b4a34c29a gdbusobjectmanagerclient: Remove an unused label
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2021-09-22 18:39:46 +01:00
Philip Withnall
8d82453cf1 gdbusobjectmanagerclient: Don’t warn if removing an interface fails
If an `InterfacesRemoved` signal is received for an object which doesn’t
exist in the local map of interfaces, don’t emit a warning.

This seems to happen in the real world (see #2401). Without a trace of
the D-Bus traffic it’s not possible to know exactly what situation is
causing this, but it seems possible that the peer could disappear and
its `notify::name-owner` signal could be processed before its
`InterfacesRemoved` signal, or something similar.

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Fixes: #2401
2021-09-22 18:34:08 +01:00
Philip Withnall
1176835ce3 Merge branch 'gitlab-ci-provide-built-dlls' into 'main'
Provide built DLLs as Gitlab-CI artifacts

To be clear, these are for testing purposes, and are not
supported releases.

See merge request GNOME/glib!2261
2021-09-22 14:23:19 +00:00
Michael Catanzaro
969a26378b Merge branch 'fix_pw_name_segfault' into 'main'
gutils: Avoid segfault in g_get_user_database_entry

See merge request GNOME/glib!2244
2021-09-22 12:46:00 +00:00
Jamie Bainbridge
bb40105fe9 gutils: Avoid segfault in g_get_user_database_entry
g_get_user_database_entry() capitalises the first letter of pw_name
with g_ascii_toupper (pw->pw_name[0]).

However, the manpage for getpwnam() and getpwuid() says the result of
those calls "may point to a static area". GLib is then trying to edit
static memory which belongs to a shared library, so segfaults.

The reentrant variants of the above calls are supposed to fill the user
buffer supplied to them, however Michael Catanzaro also found a bug in
systemd where the data is not copied to the user buffer and still points
to static memory, resulting in the same sort of segfault. See:
https://github.com/systemd/systemd/issues/20679

Solve both these cases in GLib by copying pw_name off to a temporary
variable, set uppercase on that variable, and use the variable to join
into the desired string. Free the variable after it is no longer needed.

Signed-off-by: Jamie Bainbridge <jamie.bainbridge@gmail.com>
2021-09-22 11:40:45 +10:00
Luca Bacci
2a17bac77c
Provide built DLLs as Gitlab-CI artifacts 2021-09-21 16:35:36 +02:00
Luca Bacci
0460e78bc6
GWin32AppInfo: Remove assertion on the opened registry key
Relax assertion about opened registry key as it may have been removed
in the meantime between enumeration and when opening, or (more likely)
we may not have the required permissions to open the some enumerated
keys (i.e. RegOpenKeyExW fails and returns ERROR_ACCESS_DENIED).

Fixes https://gitlab.com/inkscape/inbox/-/issues/5669
2021-09-21 16:09:23 +02:00
Vinícius dos Santos Oliveira
e26a8a5981 Add G_MAIN_CONTEXT_FLAGS_OWNERLESS_POLLING
It fixes a race. g_source_attach() had the following check to ensure a
loop blocked on poll() would wakeup.

  if (do_wakeup && context->owner && context->owner != G_THREAD_SELF)
    g_wakeup_signal (context->wakeup);

However it doesn't contemplate an implementation where poll()ing is a
non-blocking operation that will be scheduled while the thread is
released to perform other tasks. This scenario opens up several
different possibilities where the condition would fail to hold true. I
experienced two of such races.

The first race pertains to a mono-threaded application. Do keep in mind
that integrating GLib to a foreign event loop will make GLib act as a
slave in the new event loop. When you post a new work unit to execute in
the thread managed by the foreign event loop, you don't use
g_main_context_invoke(). In fact the only reason to integrate
GMainContext in a foreign event loop is to make the two of them
communicate. So from time to time, the foreign event loop will execute
callbacks that manipulate the GMainContext loop. An illustration
follows.

  // in this callback we translate an event from the foreign event loop
  // to an event in the GMainContext event loop (that runs in the same
  // thread)
  static void my_event_loop_callback(void* data)
  {
    GMainContext* ctx = /* ... */;
    // ...
    g_source_attach(source, ctx);
  }

  int main()
  {
    // ...
    my_event_loop_invoke(my_event_loop_callback, data);
    // ...

    // this function has all mechanisms in place to run the foreign
    // event loop and the hooks to call
    // g_main_context_{prepare,query,check,dispatch}
    my_event_loop_run();
  }

In this case, you would have the following series of calls:

1. g_main_context_prepare()
2. g_main_context_query()
3. A callback to my_event_loop is registered when any fd on the set is
   ready or the timeout is reached.
4. The thread is released to perform other tasks.
5. One of the tasks executed wishes to communicate with my_event_loop
   and enters my_event_loop_callback.
6. g_source_attach() is called.
7. g_source_attach() detects do_wakeup=TRUE, context->owner != NULL, and
   context->owner == G_THREAD_SELF so g_wakeup_signal() is skipped.
8. None of the fds on the GLib poll() set becomes ready nor the GLib
   timeout expires. The my_event_loop callback that would call
   g_main_context_check() is never executed. Deadlock.

A shallow analysis will fail to detect the race here. The explanation
seems to showcase a scenario that will deterministically fail with a
deadlock every time. However do keep in mind that my_event_loop_callback
could be invoked before or after g_main_context_prepare(). There is an
_event_ race here. Furthermore, some GLib libraries such as GDBus will
initialize objects from extra threads (GAsyncInitable interface) and
invoke the result on the original thread when ready (g_source_attach()
will eventually be called). Now you have scenarios closer to standard
race examples.

The other scenario where a race would manifest happens in a
multi-threaded application that has a concurrency design similar to the
actor model. No actor executes in two threads simultaneously, but it's
not guaranteed that it'll always wake-up in the same thread. It'd
perform steps 1-4 just as in the previous example, but before thread
control is returned to the pool, it'd call g_main_context_release(). Now
g_source_attach() would skip g_wakeup_signal() for a different reason:

7. g_source_attach() detects do_wakeup=TRUE, context->owner == NULL so
   g_wakeup_signal() is skipped.
8. Same as before.

Certainly there are other concurrency designs where this optimization
would cause a deadlock, but all of them have origin in the same place:
the optimization assumes the poll() implementation is a blocking
operation and the thread will never be released to perform other tasks
(possibly involving GLib calls) while result is not ready. They share
not only the same problem, but also the same solution: do not make
assumptions and just call g_wakeup_signal().

This patch implements this solution by introducing the
G_MAIN_CONTEXT_FLAGS_OWNERLESS_POLLING flag. This flag will force a call
to g_wakeup_signal() and fix the race on foreign event loops. The reason
to prevent changing this option after creation is to avoid other races
that would lead to event loss. Construction is the only proper time to
set this option.

The implementation design means we do not change **any** semantics for
current working code. If you don't set the new flag, the code won't
enter in different branches and current behavior won't be affected. The
patch is small and easy to follow too.
2021-09-21 14:50:30 +01:00
Vinícius dos Santos Oliveira
7ba86be594 Add g_main_context_new_with_flags()
This constructor is useful to set options that can't change after
creation.
2021-09-21 14:50:30 +01:00
Emmanuele Bassi
6fcad9d288 Merge branch 'open-2.71' into 'main'
Add version macros for GLib 2.72 and bump version to 2.71.0

See merge request GNOME/glib!2249
2021-09-21 13:36:42 +00:00
Philip Withnall
579ff9f6c9 Merge branch 'ebassi/floating-warning' into 'main'
Add a (diagnostic) warning for finalized floating objects

Closes #2489

See merge request GNOME/glib!2247
2021-09-21 11:09:16 +00:00
Philip Withnall
bbd1350beb Merge branch '#0434_GSequenceSlowsDown_counter' into 'main'
gsequence: make treap priorities more random to avoid worst-case scenarios

Closes #2468

See merge request GNOME/glib!2236
2021-09-21 10:40:48 +00:00
Philip Withnall
6483808df6 Merge branch 'fix-2471' into 'main'
g_output_stream_write_all: Allow NULL empty buffer

Closes #2471

See merge request GNOME/glib!2243
2021-09-21 10:40:14 +00:00
James Westman
f6ddce4b16 g_output_stream_write_all: Allow NULL empty buffer 2021-09-21 10:40:14 +00:00
Philip Withnall
45588107c6 Merge branch 'gio-add-gsettings-nullable-annotations' into 'main'
gsettings: Add various missing (nullable) or (not nullable) annotations

See merge request GNOME/glib!2242
2021-09-21 10:39:37 +00:00
Philip Withnall
b2b7feda8d Merge branch 'safer-toggle-notify' into 'main'
gobject: Ensure an object has toggle references before notifying it

Closes #2394

See merge request GNOME/glib!2072
2021-09-21 10:38:28 +00:00
Philip Withnall
afaa08142b Merge branch 'object-manager-doc-wrong-class' into 'main'
Fix documentation for g_dbus_object_manager_get_object().

See merge request GNOME/glib!2257
2021-09-21 10:19:44 +00:00
Philip Withnall
00b4547711 Merge branch 'unicode-14-updates' into 'main'
Update to Unicode 14

Closes #2490

See merge request GNOME/glib!2252
2021-09-21 09:41:29 +00:00
Matthias Clasen
ab895d91d5 Update to Unicode 14 2021-09-21 09:41:29 +00:00
Robert Ancell
e8568e25ba Fix documentation for g_dbus_object_manager_get_object().
The class in the documentation is true for GDBusObjectManagerClient, but not for GDBusObjectManagerServer.
2021-09-21 15:24:20 +12:00
Marco Trevisan (Treviño)
468246bb3b gobject: Ensure an object has toggle references before notifying it
When an object with toggle reference is notifying a change we just
assume that this is true because of previous checks.
However, while locking, another thread may have removed the toggle
reference causing the waiting thread to abort (as no handler is set at
that point).

To avoid this, once we've got the toggle references mutex lock, check
again if the object has toggle reference, and if it's not the case
anymore just ignore the request.

Add a test that triggers this, it's not 100% happening because this is
of course timing related, but this is very close to the truth.

Fixes: #2394
2021-09-20 17:56:25 +02:00
Philip Withnall
3f1a1cdb78 Merge branch 'prop-set-speedups' into 'main'
Small optimization for g_object_set

See merge request GNOME/glib!2254
2021-09-20 12:47:00 +00:00
Philip Withnall
3e57fc4c02 Merge branch 'always-cleanup-weak-locations' into 'main'
gobject: Cleanup GWeakRef locations on object finalization

Closes #2390 and #865

See merge request GNOME/glib!2064
2021-09-20 12:24:47 +00:00
Philip Withnall
3b67d53227 gobject: Clarify behaviour of adding weak refs during disposal
The previous wording was not clear about what happens if a new weak ref
is taken during disposal (shortly after resurrecting the object with a
new strong ref, otherwise taking the weak ref is invalid).

See: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/2064/diffs#note_1270092

Signed-off-by: Philip Withnall <pwithnall@endlessos.org>

Helps: #2390
2021-09-20 13:23:34 +01:00
Matthias Clasen
497986cdc1 Small optimization for g_object_setv
No need to call memset in the loop, we can just
initialize all the values in one go.

GtkBuilder is now using g_object_setv, so this
may improve application start times a bit.
2021-09-20 08:21:49 -04:00
Matthias Clasen
23e37e05d2 Small optimization for g_object_set
We've already followed the redirection, no need
to check for that again - just avoid notifying
non-readable properties.
2021-09-20 08:21:42 -04:00
Philip Withnall
97716e7b01 Merge branch 'gstring-min-size' into 'main'
GString: Bump minimum size

See merge request GNOME/glib!2251
2021-09-20 09:08:47 +00:00
Matthias Clasen
7fc7c57b6f GString: Bump minimum size
GString starts out at a size of 2, which is just
not useful. Bump the minimum size to 64 to cut
down on the number of tiny reallocations we do.
2021-09-18 20:16:57 -04:00
Philip Withnall
7692e84f0d build: Post-release version bump to 2.71.0
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2021-09-17 11:35:55 +01:00
Philip Withnall
94b74c761d gversionmacros: Add version macros for GLib 2.72
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2021-09-17 11:35:21 +01:00
Philip Withnall
861afbe639 Merge branch 'main' into 'main'
gdesktopappinfo: Do not call xterm when it does not exist, inform the caller the launch failed

See merge request GNOME/glib!2245
2021-09-17 10:28:44 +00:00
Marco Trevisan (Treviño)
a7262d6357 gobject: Cleanup weak locations data as part of dispose
Weak locations were not fully cleaned on run_dispose() and after dispose
vfunc was called, so ensure that this is the case.

Fixes: #865
2021-09-17 12:28:01 +02:00
Marco Trevisan (Treviño)
e861f60dcb gobject: Cleanup weak locations when the last one has been removed
As per the previous change, an object that had weak locations set may
need to lock again the weak locations mutex during qdata cleanup, but
we can avoid this when we know we're removing the last location, by
removing the qdata entry and freeing the data.

In case a new location is needed for the same object, new data will be
added.

However, by doing this the weak locations during dispose may be
invalidated once the weak locations lock is passed, so check again if
this is the case while removing them.
2021-09-17 12:27:59 +02:00
Marco Trevisan (Treviño)
ea68b22135 gobject: Cleanup GWeakRef locations on object finalization
It can happen that a GWeakRef is added to an object while it's disposing
(or even during finalizing) and this may happen in a thread that (weak)
references an object while the disposal isn't completed yet or when
using toggle references and switching to GWeakRef on notification (as
the API suggests).

In such scenario the weak locations are not cleaned up when the object
is finalized, and will point to a free'd area.

So, during finalization and when we're sure that the object will be
destroyed for sure, check again if there are new weak locations and
unset them if any as part of the qdata destruction.
Do this adding a new utility function so that we can avoid duplicating
code to free the weak locations.

Added various tests simulating this case.

Fixes: #2390
2021-09-17 12:21:23 +02:00
Philip Withnall
6fd4f36bac 2.70.0
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
2021-09-17 11:15:53 +01:00
Zander Brown
1da68b3f06 Update British English translation 2021-09-16 16:45:30 +00:00