Commit Graph

31567 Commits

Author SHA1 Message Date
Michael Catanzaro
aab8cf8a2b Merge branch 'backport-4708-filename-completer-free-undefined-glib-2-84' into 'glib-2-84'
Backport !4708 “gfilenamecompleter: Fix g_object_unref() of undefined value” to glib-2-84

See merge request GNOME/glib!4711
2025-07-22 08:48:28 -05:00
Philip Withnall
c537ffd4a5 gfilenamecompleter: Fix g_object_unref() of undefined value
If the first `goto out` is taken, `file` has not yet been initialised,
but `g_clear_object (&file)` is called on it, and things get unhappy.

Fix that by following standard convention and initialising
‘autoptr’-like variables at declaration time.

Spotted by scan-build in
https://gitlab.gnome.org/GNOME/glib/-/jobs/5321883.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2025-07-22 14:00:49 +01:00
Michael Catanzaro
f5a5c2a9b3 Merge branch 'backport-4702-filename-completer-leaks-glib-2-84' into 'glib-2-84'
Backport !4702 “gio/filenamecompleter: Fix leaks” to glib-2-84

See merge request GNOME/glib!4705
2025-07-21 18:08:03 -05:00
Khalid Abu Shawarib
416ce207a8 gio/filenamecompleter: Fix leaks 2025-07-21 19:03:54 +01:00
Michael Catanzaro
5491737651 Merge branch 'backport-4696-thread-error-handling-glib-2-84' into 'glib-2-84'
Backport !4696 “gthreadpool: Catch pool_spawner creation failure” to glib-2-84

See merge request GNOME/glib!4697
2025-07-18 14:02:41 -05:00
Peter Bloomfield
a139db3dc8 gthreadpool: Catch pool_spawner creation failure 2025-07-17 23:50:08 +01:00
Michael Catanzaro
ba54be80f4 Merge branch 'backport-4677-4678-display-name-leaks-glib-2-84' into 'glib-2-84'
Backport !4677 and !4678 “Fix GFile leak in g_local_file_set_display_name()” to glib-2-84

See merge request GNOME/glib!4679
2025-07-07 08:12:21 -05:00
Philip Withnall
e519e5489d glocalfile: Fix another leak in g_local_file_set_display_name()
Signed-off-by: Philip Withnall <pwithnall@gnome.org>

Fixes: #3721
2025-07-07 13:32:15 +01:00
Michael Catanzaro
4f6dbf1d5e Fix GFile leak in g_local_file_set_display_name()
Fixes #3721
2025-07-07 13:32:08 +01:00
Michael Catanzaro
b9c66f4fae Merge branch 'backport-4674-tmp-file-name-glib-2-84' into 'glib-2-84'
Backport !4674 “gfileutils: fix computation of temporary file name” to glib-2-84

See merge request GNOME/glib!4675
2025-07-01 13:07:54 -05:00
Michael Catanzaro
8f4da99bf2 gfileutils: fix computation of temporary file name
We need to ensure that the value we use to index into the letters array
is always positive.

Fixes #3716
2025-07-01 18:17:47 +01:00
Michael Catanzaro
04fb764d46 Merge branch 'backport-4667-settings-binding-glib-2-84' into 'glib-2-84'
Backport !4667 “Incorrect output parameter handling in closure helper of g_settings_bind_with_mapping_closures” to glib-2-84

See merge request GNOME/glib!4668
2025-06-23 12:51:28 -05:00
Mark Nauwelaerts
a509aa1f6f gsettings: adjust closure helpers in g_settings_bind_with_mapping_closures
... to handle an output value parametere
2025-06-19 13:35:12 +01:00
Mark Nauwelaerts
9625907af0 tests: gsettings: extend g_settings_bind_with_mapping_closures test
... so as to fail with current implementation
2025-06-19 13:35:12 +01:00
Philip Withnall
78cd78d298 2.84.3
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2.84.3
2025-06-13 12:55:59 +01:00
Emmanuele Bassi
37eecaa7ef Merge branch 'backport-4655-string-overflow-check-glib-2-84' into 'glib-2-84'
Backport !4655 “gstring: Fix overflow check when expanding the string” to glib-2-84

See merge request GNOME/glib!4656
2025-06-03 14:09:54 +01:00
Philip Withnall
987309f23a gstring: Fix overflow check when expanding the string
After commit 34b7992fd6 the overflow check
was only done when expanding the string, but we need to do it before
checking whether to expand the string, otherwise that calculation could
overflow and falsely decide that the string is big enough already.

As a concrete example, consider a `GString` which has:
 * `.len = G_MAXSIZE / 2 + 1`
 * `.allocated_len = G_MAXSIZE / 2 + 1`
and `g_string_append()` is called on it with an input string of length
`G_MAXSIZE / 2`.

This results in a call `g_string_maybe_expand (string, G_MAXSIZE / 2)`,
which calculates `string->len + len` as `(G_MAXSIZE / 2 + 1) +
(G_MAXSIZE / 2)` which evaluates to `1` as it overflows. This is not
greater than `string->allocated_len` (which is `G_MAXSIZE / 2 + 1`), so
`g_string_expand()` is *not* called, and `g_string_maybe_expand()`
returns successfully. The caller then assumes that there’s enough space
in the buffer, and happily continues to cause a buffer overflow.

It’s unlikely anyone could hit this in practice because it requires
ludicrously big strings and `GString` allocations, which likely would
have been blocked by other code, but if we’re going to have the overflow
checks in `GString` then they should be effective.

Spotted by code inspection.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2025-06-03 13:09:24 +01:00
Philip Withnall
2371bee17d 2.84.2
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2.84.2
2025-05-20 17:22:25 +01:00
Michael Catanzaro
11f7217871 Merge branch 'backport-4620-android-faccessat-glib-2-84' into 'glib-2-84'
Backport !4620 “glocalfile: Disable faccessat()-based query_exists on Android” to glib-2-84

See merge request GNOME/glib!4640
2025-05-20 11:11:56 -05:00
Colin Kinloch
cf50c06ee3 glocalfile: Disable faccessat()-based query_exists on Android
The bionic version of faccessat() returns EINVAL when flags are set.

See 35778253a5
2025-05-20 16:17:02 +01:00
Michael Catanzaro
64c9c40719 Merge branch 'backport-4590-wsign-conversion-locale-variants-glib-2-84' into 'glib-2-84'
Backport -Wsign-conversion fixes for g_get_locale_variants() from !4590 to glib-2-84

See merge request GNOME/glib!4639
2025-05-20 09:38:13 -05:00
Philip Withnall
99bda30d84 gcharset: Fix potential negative string offsets in g_get_locale_variants()
The parser was assuming that all three separators (`_@.`) were in order;
but the input might not contain them in order. In that case, the parser
would have passed negative values to `g_strndup()` which would have been
implicitly cast to large positive values, and potentially exposed a lot
of memory (until the first nul byte, which was probably quite soon).

Expand the existing `g_get_locale_variants()` test to cover some invalid
parsing, and add a fuzzing test too.

Spotted by `-Wsign-conversion`.

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

Helps: #3405
2025-05-20 14:51:03 +01:00
Philip Withnall
5f7679ba10 tests: Use g_assert_*() rather than g_assert() in utils tests
It won’t get compiled out with `G_DISABLE_ASSERT`.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2025-05-20 14:50:47 +01:00
Marco Trevisan
b3de15acf9 Merge branch 'backport-4617-tzset-glib-2-84' into 'glib-2-84'
Backport !4617 “gdate: Call tzset before localtime_r” to glib-2-84

See merge request GNOME/glib!4623
2025-05-06 13:33:37 +00:00
Alessandro Astone
23c78b429f gdate: Call tzset before localtime_r
From `man 3 ctime`:
  According to POSIX.1, localtime() is required to behave as though tzset(3)
  was called, while localtime_r() does not have this requirement.
  For portable code, tzset(3) should be called before localtime_r().
2025-05-06 12:26:04 +01:00
Philip Withnall
48466f3a61 Merge branch 'macos_ci_284' into 'glib-2-84'
Backport !4613 “Update macOS job for new CI runner” to glib-2-84

See merge request GNOME/glib!4616
2025-04-30 02:52:25 +00:00
René de Hesselle
2d07e766ca ci: Update macOS job for new CI runner
Remove settings no longer required on an ephemeral runner (redirecting
cache locations etc.).

Adjust cache settings.

(cherry picked from commit dc23a17fb1)
2025-04-29 22:46:52 +02:00
Marco Trevisan
e2ed5efc0e Merge branch 'cherry-pick-cc647f9e' into 'glib-2-84'
Backport "gstring: carefully handle gssize parameters"

See merge request GNOME/glib!4614
2025-04-29 02:37:52 +00:00
Peter Bloomfield
f32f4aea51 gstring: Make len_unsigned unsigned 2025-04-28 14:34:55 -05:00
Michael Catanzaro
a47dc88946 gstring: carefully handle gssize parameters
Wherever we use gssize to allow passing -1, we need to ensure we don't
overflow the value by assigning a gsize to it without checking if the
size exceeds the maximum gssize. The safest way to do this is to just
use normal gsize everywhere instead and use gssize only for the
parameter.

Our computers don't have enough RAM to write tests for this. I tried
forcing string->len to high values for test purposes, but this isn't
valid and will just cause out of bounds reads/writes due to
string->allocated_len being unexpectedly small, so I don't think we can
test this easily.


(cherry picked from commit cc647f9e46)

Co-authored-by: Michael Catanzaro <mcatanzaro@redhat.com>
2025-04-28 16:03:08 +00:00
Michael Catanzaro
7ca5c651bd Merge branch 'revert-c2262cd7' into 'glib-2-84'
Revert "Merge branch 'backport-4607-gfileutils-preserve-mode' into 'glib-2-84'"

See merge request GNOME/glib!4612
2025-04-25 21:44:05 +00:00
Michael Catanzaro
a8b9bc5d36 Revert "Merge branch 'backport-4607-gfileutils-preserve-mode' into 'glib-2-84'"
This reverts merge request !4608
2025-04-25 21:24:16 +00:00
Michael Catanzaro
c2262cd753 Merge branch 'backport-4607-gfileutils-preserve-mode' into 'glib-2-84'
Backport "gfileutils: Preserve mode during atomic updates"

See merge request GNOME/glib!4608
2025-04-24 18:31:40 +00:00
Wesley Hershberger
3cc0c0de33 gfileutils: Preserve mode during atomic updates
If g_file_set_contents{_full,} is replacing an existing file, require
that the tmpfile have the same mode as the existing file.

This prevents the umask from taking effect for consistent writes to
existing files.

Closes GNOME/dconf#76
2025-04-24 11:54:38 -05:00
Michael Catanzaro
437f3a134d Merge branch 'backport-4582-windows-typelib-path-glib-2-84' into 'glib-2-84'
Backport !4582 “Windows: fix wrong typelib path” to glib-2-84

See merge request GNOME/glib!4595
2025-04-14 14:31:06 +00:00
Dan Yeaw
b593c1551b Windows: fix wrong typelib path 2025-04-12 16:52:44 +01:00
Michael Catanzaro
f91e47888f Merge branch 'backport-4575-closure-race-fix-glib-2-84' into 'glib-2-84'
Backport !4575 “gclosure: fix ATOMIC_CHANGE_FIELD to read vint atomically” to glib-2-84

See merge request GNOME/glib!4576
2025-04-04 14:05:12 +00:00
Sam James
190d6d3a91 gclosure: fix ATOMIC_CHANGE_FIELD to read vint atomically
Depending on luck, g_closure_ref may access closure->vint and observe
different values between reads. This manifests as a test failure in
signals-refcount{2,4}, properties-refcount1, and closure-refcount depending
on timing and re-runs.

Jakub Jelinek analysed this on GCC bug PR119607 after I'd reported it
over there as a possible GCC regression.

The critical part being g_closure_ref -> ATOMIC_INC_ASSIGN -> ATOMIC_CHANGE_FIELD
where closure->vint gets re-read repeatedly, both outside and inside the retry
loop. To fix that:

1. Atomically fetch it the first time;
2. Use the cached read, not a fresh read, of vint in the loop;
3. Use g_atomic_int_compare_and_exchange_full in the loop so we get a freshly
cached vint if it changed in another thread.

Bug: https://gcc.gnu.org/PR119607
Fixes: 834ddd19 ('turned all modifications to the first 32 integer bits in a closure into')
Co-authored-by: Jakub Jelinek <jakub@redhat.com>
2025-04-03 23:40:30 +01:00
Philip Withnall
eaa7e5bdfd 2.84.1
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2.84.1
2025-04-03 15:38:51 +01:00
Philip Withnall
d854836aff girparser: Fix a strict-aliasing warning with g_clear_pointer()
Casting the type for a `g_clear_pointer()` call breaks strict aliasing
rules.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2025-04-03 15:38:45 +01:00
Philip Withnall
29e27d8dcd Merge branch 'cancellable-connection-fixes' into 'main'
cancellable: Fix connect and disconnect references handling

Closes #3642 and #3643

See merge request GNOME/glib!4573
2025-04-03 13:55:49 +00:00
Marco Trevisan (Treviño)
a2f98c86ff gio/cancellable: Never call toggle notify callback in locked state
We had code to avoid that we could call a toggle "up" notification
callback in locked state, but this was not covering the case in which
the cancellable second to last reference was removed in its cancellation
callback.

In fact, in such case we end up going from 2 -> 1 references during the
signal callback call and this leads to calling the toggle notify
callback in locked state.

To prevent this, add an even further reference before calling the
callback (in locked state, but there's no risk that a toggle-up
notification happens now), and drop it once unlocked again.
2025-04-03 15:22:16 +02:00
Marco Trevisan (Treviño)
ec2fee555f gio/cancellable: Do not call data destroy function while locked
If when calling g_cancellable_connect() the cancellable was already
cancelled we could have ended up in calling the data cleanup
function while the cancellable lock was held.

This is likely not an issue, but it's still better not to do it,
so protect the code against it
2025-04-03 15:22:16 +02:00
Marco Trevisan (Treviño)
c6ace7aaf7 gio/cancellable: Fix comments for g_cancellable_connect()
We had wrong comments, in particular:

  @callback is called exactly once each time @cancellable is cancelled,
  either directly at the time of the connect if @cancellable is already
  cancelled, or when @cancellable is cancelled in some thread.
  In case the cancellable is reset via [method@Gio.Cancellable.reset]
  then the callback can be called again if the @cancellable is cancelled

This is not true if `@cancellable` is already cancelled because then the
callback will be thrown away, and will not be called for subsequent
cancellations.

  Since GLib 2.40, the lock protecting @cancellable is not held when
  @callback is invoked.  This lifts a restriction in place for
  earlier GLib versions which now makes it easier to write cleanup
  code that unconditionally invokes e.g. g_cancellable_cancel().

As per commit 3a07b2abd4 this section needs some amending since
it's not true anymore, as the GCancellable's mutex is held when `@callback` is
invoked. However this happens in a way that it's still safe to call most
of the GCancellable API.

Closes: #3642
2025-04-03 15:22:16 +02:00
Philip Withnall
7ea714e658 Merge branch 'wip/3v1n0/sanitizer-memory-fixes' into 'main'
Memory sanitizer fixes

See merge request GNOME/glib!4484
2025-04-03 13:04:05 +00:00
Marco Trevisan (Treviño)
49680afd5c gio/cancellable: Always add reference while emitting cancelled signal
When a non-cancelled cancellable ::cancelled signal callback is called
the cancellable has enough references so that it can be unreferenced on
the callback itself. However this doesn't happen if the cancellable has
been already cancelled at the moment we connect to it.

To prevent this, add a temporary reference before calling the signal
callback.

Note that we do this also if the callback has not been already cancelled
to prevent that we may end up calling a toggle-notify callback while we
are locked.

Add tests

Closes: #3643
2025-04-03 14:48:57 +02:00
Marco Trevisan (Treviño)
7432441581 test/cancellable: Check that a cancellable can be unreffed on callback
This works when the cancellable has not been cancelled yet.
2025-04-03 14:48:56 +02:00
Marco Trevisan (Treviño)
03dcf4cdc3 glib/messages: Avoid warning on potentially uninitialized value
In function ‘memmem_with_end_pointer’,
    inlined from ‘domain_found’ at ../glib/gmessages.c:2695:16,
    inlined from ‘should_drop_message’ at ../glib/gmessages.c:2802:35:
../glib/gmessages.c:2674:19: warning: ‘log_domain_length’ may be used
    uninitialized [-Wmaybe-uninitialized]
 2674 | #define my_memmem memmem
      |                   ^
../glib/gmessages.c:2683:10: note: in expansion of macro ‘my_memmem’
 2683 |   return my_memmem (haystack, (const char *) haystack_end - (const char *) haystack, needle, needle_len);
      |          ^~~~~~~~~
../glib/gmessages.c: In function ‘should_drop_message’:
../glib/gmessages.c:2760:13: note: ‘log_domain_length’ was declared here
 2760 |       gsize log_domain_length;
      |             ^~~~~~~~~~~~~~~~~
2025-04-03 14:01:20 +02:00
Marco Trevisan (Treviño)
31c9dbbc73 glib/tests/gvariant: Not try to memcpy NULL data
It's undefined behavior
2025-04-03 13:58:15 +02:00
Marco Trevisan (Treviño)
39c05b1312 gvariant-core: Add pre-condition on variant store data being non-null
We define the data not-nullable in docs, but we didn't check this
prerequisite programmatically
2025-04-03 13:58:15 +02:00