9135 Commits

Author SHA1 Message Date
Rafael Girão
ce3a5dbbbe glib: respect symlinks when updating mimeapps.list
In the case where mimeapps.list is a symlink, gio-issued updates would
overwrite the file, destroying the symlink in the process.

Instead, this approach recursively follows mimeapps.list symlinks
and overwites the contents of the final file instead.

Closes #3579
2025-08-18 13:44:23 +00:00
Philip Withnall
30aff12d89 gmemorymonitorpoll: Hold a weak ref from a source callback to the monitor
It’s possible for the dispatch of the timeout source to race with the
finalisation of the `GMemoryMonitorPoll`, given that the timeout is run
in the GLib worker thread.

Protect against that by holding a thread-safe weak ref on the
`GMemoryMonitor` in the callback data.

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

Fixes: #3758
2025-08-12 13:24:52 +01:00
Niveditha Rau
365c5bcfd1 Disable GMemoryMonitorPsi on Solaris
PSI doesn’t exist in the Solaris kernel, so this `GMemoryMonitor`
implementation can never be chosen at runtime on Solaris.
2025-08-12 08:31:04 +00:00
Tobias Stoeckmann
b8f9743a4d systemtap: Use correct formatters/types
Try to avoid casting variables to potentially smaller types to fit
defined probes. This can truncate values and lead to wrong results.

Also make sure that signedness matches.

Since GType can be even 128 bit on CHERI architecture, cast all these
various types used based on platform to uintmax_t which SystemTap
properly processes.
2025-08-08 23:15:38 +02:00
Antoine Jacoutot
ff47c01818 glocalfile: Disable faccessat()-based query_exists on OpenBSD 2025-08-07 11:28:25 +00:00
Khalid Abu Shawarib
7a38cbc1dc gio/filenamecompleter: Use platform-specific directory separator 2025-08-05 17:36:41 +03:00
Khalid Abu Shawarib
48f8812cca gio/tests/filenamecompleter: Add a basic test 2025-08-05 17:36:00 +03:00
Khalid Abu Shawarib
f9592306c9 gio/filenamecompleter: Add more specifics to documentation
Also remove redundant things like asking a user to free a string,
as it is already covered by transfer type annotations.
2025-08-05 17:36:00 +03:00
Philip Withnall
da19665880 Merge branch 'gdbuserror-docs' into 'main'
gdbuserror: Reformat docs to fully use gi-docgen and match style guide

See merge request GNOME/glib!4715
2025-08-05 13:20:06 +00:00
Philip Withnall
d6ba42a489 gdbuserror: Reformat docs to fully use gi-docgen and match style guide
https://developer.gnome.org/documentation/guidelines/devel-docs.html#writing-api-references

Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3250
2025-08-05 13:57:40 +01:00
Luca Bacci
12543df16f Tests: do not set a timeout in Python tests
The Meson test harness handles that for us.

With a custom timeout, meson test -t is not useful (which is
surprising for users) and interactive debugging sessions may
terminate unexepectedly.
2025-08-04 10:47:50 +02:00
Philip Withnall
2326db507d tests: Add a missing poll condition to socket-listener test
It’s possible for the server communications to finish one main context
iteration before all of the client communications, depending on how the
kernel queues socket connection messages.

Fixes CI failure: https://gitlab.gnome.org/GNOME/glib/-/jobs/5341950

```
GLib-GIO:ERROR:../gio/tests/socket-listener.c:639:test_accept_multi_simultaneously: 'clients[i].result' should not be NULL
not ok /socket-listener/accept/multi-simultaneously - GLib-GIO:ERROR:../gio/tests/socket-listener.c:639:test_accept_multi_simultaneously: 'clients[i].result' should not be NULL
```

Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2025-07-31 00:11:25 +01:00
Michael Catanzaro
364f33c168 Merge branch '3739-socket-listener-keeps-on-giving' into 'main'
gsocketlistener: Fix accepting multiple connections in a single GMainContext iteration

Closes #3739

See merge request GNOME/glib!4717
2025-07-28 02:04:34 -05:00
Philip Withnall
8b82fb34c9 gsocketlistener: Fix infinite blocking when accepting connections
As the new comments in the code try to explain, this fixes infinite
blocking which could happen when calling
`g_socket_listener_accept_async()` multiple times in parallel, with more
parallel calls than there are pending incoming connections on any of the
`GSocket`s in the `GSocketListener`.

The way `g_socket_listener_accept_async()` works is to create a set of
`GSocketSource`s when it’s called, one for each of the `GSocket`s in the
`GSocketListener`. Those sources are attached to the main context,
polling for `G_IO_IN` (indicating that the socket has a pending incoming
connection to accept).

When one of the socket sources polls ready, `g_socket_accept()` is
called on it, and a new connection is created.

If there are multiple pending `g_socket_listener_accept_async()` calls,
there are correspondingly multiple `GSocketSource` sources for each
`GSocket` in the `GSocketListener`. They will all poll ready in a single
`GMainContext` iteration. The first one to be dispatched will
successfully call `g_socket_accept()`, and subsequent ones to dispatch
will do likewise until there are no more pending incoming connections.
At that point, any remaining socket sources polling ready in that
`GMainContext` iteration will call `g_socket_accept()` on a socket which
is *not* ready to accept, and that will block indefinitely, because
`GSocket` has its own blocking layer on top of `poll()`.

This is not great.

It seems like a better approach would be to disable `GSocket`’s blocking
code, because `GSocketListener` is using `poll()` directly. We only need
one source of poll truth. So, do that.

Unfortunately, that’s complicated by the fact that
`g_socket_listener_add_socket()` allows third party code to provide its
own `GSocket`s to listen on. We probably can’t unilaterally change those
to non-blocking mode, so users of that API will get what they ask for.
That might include blocking indefinitely. I’ve adjusted the
documentation to mention that, at least.

The changes are fairly simple; the accompanying unit test is less
simple. Shrug. It tests for the scenario fixed by this commit, plus the
scenario fixed by the previous commit.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3739
2025-07-25 16:36:33 +01:00
Philip Withnall
5ccce023de gsocketlistener: Fix a use-after-free when accepting sockets
The changes in commit 30ccfac9cf were not quite correct. The code is
structured so that a single reference to a `GTask` (and hence its
`AcceptSocketAsyncData` task data) is shared across the multiple
`GSocketSource`s which are created for a pending `accept_async()` call.

Setting `returned_yet` to true to short-circuit the remaining
`accept_ready()` dispatches in a given `GMainContext` iteration would
have worked, were it not for the fact that the code then immediately
dropped the last reference it had to the `GTask`, potentially freeing
the structure which contained `returned_yet`. Because of the async
nature of `GTask`, the exact timing of finalisation could vary.

This also meant that the other `GSocketSource`s were not destroyed until
an unknown time later.

Improve on that by explicitly destroying the other `GSocketSource`s as
soon as the first one returns an accepted socket. This causes
`GMainContext` to skip dispatching them, even within the same
`GMainContext` iteration. It also means the separate `returned_yet`
member is unnecessary.

This should fix the immediate issue seen in #3739. However, while
testing it I found a further issue which will be fixed in a following
commit, before I add a unit test.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3739
2025-07-25 16:04:44 +01:00
Philip Withnall
0558fc541e gsocketlistener: Factor out code to add sockets to internal structures
This introduces no functional differences, just makes some upcoming
changes clearer.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3739
2025-07-25 16:04:37 +01:00
Philip Withnall
4e1fcbffbd gsocket: Handle cancellation of connect() in non-blocking mode
As with the previous commit, but for `g_socket_connect()`, which is the
other cancellable use of `g_socket_condition_wait()` in the file.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2025-07-25 15:29:51 +01:00
Philip Withnall
e6a1eacfe1 gsocket: Handle cancellation of accept() in non-blocking mode
Currently, if `g_socket_accept()` is called with a cancelled cancellable
and the socket is in non-blocking mode, `G_IO_ERROR_CANCELLED` is not
returned, because the cancellable is only checked in the call to
`g_socket_condition_wait()`, which only happens in blocking mode.

Fix that and add a unit test.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3739
2025-07-25 15:20:13 +01:00
Philip Withnall
b142f130b1 Merge branch 'memory-monitor-race' into 'main'
tests: Connect to GMemoryMonitor signals earlier

See merge request GNOME/glib!4709
2025-07-25 00:24:47 +00:00
Philip Withnall
341cd08a42 gmemorymonitorbase: Emit signals in the global default main context
`GMemoryMonitor` is a singleton, which means we can’t use the usual
approach of emitting signals in the thread-default main context from the
time of construction of the object.

The next best thing is to emit them in the global default main context.
For many applications, this will be exactly what they are expecting. For
multi-threaded applications, they will need to implement their own
thread safety in the signal handler, but they would have to do that
anyway.

Currently, the signals are emitted in the GLib worker thread (for the
PSI and poll implementations of `GMemoryMonitor`) — this is the worst
option, because it means that third party signal handlers could block
the worker thread (which is precisely what the worker thread is meant to
avoid).

Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2025-07-23 13:27:58 +01:00
Kate Hsuan
7e7c452d4a gio: gmemorymonitorpsi: Fix test error since memory free ratio test can be skipped when performing the test
The memory free ratio test can be skipped when we run the test. If
proc_override is TRUE and proc path is overridden, the memory free
ratio test can be skipped.
2025-07-23 20:13:19 +08:00
Kate Hsuan
e9b0fe2879 gio: gmemorymonitorpoll: Fix unit test error since the callback returns earlier
The value overriding has to be set before testing the value and returning
the callback. Otherwise, the callback can't emit a signal to the test
program.
2025-07-23 20:09:26 +08:00
Philip Withnall
ee5e750be3 tests: Connect to GMemoryMonitor signals earlier
It might be possible for the `low-memory-warning` signal to be emitted
(by the GLib worker thread) before the test has connected to it, which
could cause the tests to loop forever.

Potentially fixes
https://gitlab.gnome.org/pwithnall/glib/-/jobs/5322491, though I have
not been able to reproduce the race locally.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2025-07-22 13:33:24 +01:00
Philip Withnall
a41d1681be 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 12:57:14 +01:00
Philip Withnall
8b9c9e76f3 Merge branch 'kate/replace-backend' into 'main'
gio: gmemorymonitorpsi: Replace GMemoryMonitor backend with kernel PSI event

See merge request GNOME/glib!4481
2025-07-21 17:32:21 +00:00
Kate Hsuan
7518406d08 gio: tests: memory-monitor-psi: test for the PSI backend of GMemoryMonitor
This tests the PSI backend when receiving the signal.
2025-07-21 17:39:25 +01:00
Kate Hsuan
caffa53bca gio: tests: memory-monitor-poll: test for the poll backend of GMemoryMonitor
The unit test inplementation for GMemoryMonitor poll backend. The test includes
loading the API and the signals of LOW, MEDIUM, and CRITICAL level.
2025-07-21 17:39:25 +01:00
Kate Hsuan
32ea357130 gio: gmemorymonitorpoll: Poll backend for the GMemoryMonitor
This backend periodically watch the memory free ratio through sysinfo().
It signals the applications when the memory free ratio drops to 40%, 30%,
and 20% for LOW, MEDIUM, CRITICAL status, respectively.
2025-07-21 17:39:25 +01:00
Kate Hsuan
308709b8d9 gio: gmemorymonitorpsi: Kernel PSI backend for GMemoryMonitor
The PSI backend is based on Kernel PSI [1]. It monitors the memory
allocation time with in a given time window. If the allocation time
is more than the given threshold, Kernel signal the application to
deliver the memory pressure events.

The current thresholds are:
LOW: 70ms out of 2 seconds for partial stall
MEDIUM: 100ms out of 2 seconds for partial stall
CRITICAL: 100ms out of 2 seconds for full stall

[1] https://docs.kernel.org/accounting/psi.html
2025-07-21 17:39:25 +01:00
Kate Hsuan
94e6da0fca gio: gmemorymonitorbase: parent class of GMemoryMonitor backends
This class provides the shared functions, such as sending a signal and
string and value conversion. The backend classes should inherit this
class to get the shared functions.

It adds a configure time check for `sysinfo()`, as some systems don’t
have it.
2025-07-21 16:09:46 +01:00
Philip Withnall
cc65d91559 tests: Add a regression test for GApplication command line handling
This will catch regressions like
fc030b2b64 if they happen again in future,
by testing that fallback argument parsing code path in
`g_application_run()`.

Heavily based on the PyGObject `test_local_and_remote_command_line` unit
test at
578a55982a/tests/test_gio.py (L289).

Thanks to Arjan Molenaar for investigating the failure and writing it
up in !4703.

Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2025-07-21 12:52:20 +01:00
Philip Withnall
96c9b5e0cc Merge branch 'fix-command-line-options-ref' into 'main'
application: NULL check for options

See merge request GNOME/glib!4703
2025-07-21 11:20:39 +00:00
Arjan Molenaar
fc030b2b64 application: NULL check for options
Do an extra check if the options argument is NULL,
This will avoid unnessecary (critical warning).

`g_application_run` calls the code with options == NULL.
2025-07-20 16:40:13 +02:00
Khalid Abu Shawarib
3d13946c3b gio/filenamecompleter: Fix leaks 2025-07-20 04:57:01 +03:00
Philip Withnall
41fe7c3797 tests: Loosen string comparison assertion in gio-tool.py
On BSD, the subprocess being spawned by `gio launch` ends up emitting
debug output onto stdout, which confuses the strict string assertion in
the test.

Instead use a ‘contains’ assertion.

Fixes this failure:
```
348/385 glib:gio+no-valgrind / gio-tool.py                                     ERROR            0.39s   exit status 1
――――――――――――――――――――――――――――――――――――― ✀  ―――――――――――――――――――――――――――――――――――――
stderr:
(test program exited with status code 1)
――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――
stdout:  12: UNKNOWN:   ---
stdout:  13: UNKNOWN:     message: |
stdout:  14: UNKNOWN:       Traceback (most recent call last):
stdout:  15: UNKNOWN:         File "/var/tmp/gitlab_runner/builds/Ff4WDDRj/0/GNOME/glib/_build/../gio/tests/gio-tool.py", line 130, in test_absolute_from_folder
stdout:  16: UNKNOWN:           self.launchAndCheck(self.entry, cwd=self.folder)
stdout:  17: UNKNOWN:         File "/var/tmp/gitlab_runner/builds/Ff4WDDRj/0/GNOME/glib/_build/../gio/tests/gio-tool.py", line 126, in launchAndCheck
stdout:  18: UNKNOWN:           self.assertEqual(result.out, str(self.entry))
stdout:  19: UNKNOWN:       AssertionError: '(gio launch:35500): GLib-GIO-DEBUG: 04:55[130 chars]ntry' != '/tmp/tmpa8oxxwvv/folder/desktop.entry'
stdout:  20: UNKNOWN:       - (gio launch:35500): GLib-GIO-DEBUG: 04:55:51.790: _g_io_module_get_default: Found default implementation local (GLocalVfs) for ‘gio-vfs’
stdout:  21: UNKNOWN:         /tmp/tmpa8oxxwvv/folder/desktop.entry
stdout:  22: UNKNOWN:   ...
```

seen here: https://gitlab.gnome.org/GNOME/glib/-/jobs/5301812

Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2025-07-15 12:26:43 +01:00
Matthias Clasen
1bb48a76a6 application: Call before/after_emit consistently
Call these vfuncs also for cases where the launching instance
is the primary one. This is what the docs suggest, and it makes
before/after_emit much more useful.

Fixes: #3726
2025-07-11 07:33:02 -04:00
Matthias Clasen
182185e31e application: Clarify documentation
Existing uses of before_emit in GTK will break if an app overrides
before/after_emit without chaining up. Clarify in the documentation
that these vfuncs need to chain up.
2025-07-11 07:33:02 -04:00
Matthias Clasen
de85736791 tests: Remove an overzealous assertion
The dbus-appinfo test was asserting that before_emit only happens
when we haven't seen a startup ID yet. But the docs imply that it
gets emitted for every activate/open/commandline, which may well
happen repeatedly. So drop this assertion.
2025-07-11 07:33:02 -04:00
Philip Withnall
5da569a425 Merge branch 'pgriffis/ipv6-scope-id' into 'main'
Fix IPv6 scope-id from DNS responses being lost

See merge request GNOME/glib!4676
2025-07-09 14:00:18 +00:00
Christoph Martin
e2970dad72 tests: skip gio launch tests on darwin
Tests currently fail under macOS because the tool claims not to work
on apple devices. Since I cannot disprove this myself, I'm disabling the
tests on Darwin.
2025-07-09 13:39:34 +01:00
Christoph Martin
c924de69f0 gio-tool-launch: fix %k field code expansion
As per the desktop entry specification, the `%k` field code should be
expanded to the location of the desktop entry file being processed. This
is only possible if the constructor-only filename property is populated,
which does not happen when using g_desktop_app_info_new_from_keyfile().

Moreover, since the Path directive in a desktop entry can be used to
set the working directory for the program to be launched, the location
passed as argument to the program must be modified such that it points
at the correct file when interpreted by the launched program. The
simplest way to achieve this consistently is to pass an absolute path.

However, g_desktop_app_info_new_from_keyfile() does not indicate why it
fails when it does. Because the tool aims to indicate whether launching
failed due to a missing file or a malformed one we first check this with
g_key_file_load_from_file().
2025-07-09 13:39:34 +01:00
Christoph Martin
c2debf4fa9 tests: ensure gio launch expands field code %k
This introduces an integration test that executes gio launch from a
variety of working directories, and checks that %k is expanded to a
location that makes sense in the context of the executed program, i.e.
an absolute path.
2025-07-09 13:39:34 +01:00
Michael Catanzaro
25a176869d Merge branch 'gio-launch-quotes' into 'main'
gio-tool-launch: Fix mismatched curly quotes in translatable strings

See merge request GNOME/glib!4683
2025-07-08 08:05:40 -05:00
Philip Withnall
8b05d8e95d gio-tool-launch: Fix mismatched curly quotes in translatable strings
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
2025-07-08 11:11:40 +01:00
Patrick Griffis
e419c1e10d inet-address: Ignore windows specific failure
In this case getaddrinfo on Windows succeeds at parsing something that fails on Linux.
2025-07-07 15:45:50 -05:00
Patrick Griffis
7e85ae9d5f ginetaddress: Scope ID parsing is not supported on win32
getaddrinfo doesn't parse it on Windows. This could be replaced by more manual parsing in the future.
2025-07-07 11:24:11 -05:00
Philip Withnall
d0f31c23d5 Merge branch 'fix_file_enumerator' into 'main'
gio: call g_file_enumerator_close in dispose instead of finalize

Closes #3713

See merge request GNOME/glib!4672
2025-07-07 12:35:50 +00:00
fbrouille
02597ca9d2 gio: call g_file_enumerator_close in dispose
`g_file_enumerator_finalize` should not call `g_file_enumerator_close`
because object parts (i.e. subclass variable and/or resources) might
already be freed, causing memory safety issues.
A better place to call `g_file_enumerator_close` is
`g_file_enumerator_dispose` because it is safe to access the object
memory here.

Fixes #3713

Signed-off-by: fbrouille <150549-fbrouille@users.noreply.gitlab.gnome.org>
2025-07-07 13:01:49 +01:00
Philip Withnall
acfe9d043f glocalfile: Fix another leak in g_local_file_set_display_name()
Signed-off-by: Philip Withnall <pwithnall@gnome.org>

Fixes: #3721
2025-07-07 12:58:59 +01:00
Marco Trevisan
29b47390c5 Merge branch 'mcatanzaro/#3721' into 'main'
Fix GFile leak in g_local_file_set_display_name()

Closes #3721

See merge request GNOME/glib!4677
2025-07-07 03:40:47 +02:00