GitLab

tests: Fix intermittent failure in GCancellableSource test

Closes #1764

See merge request !1539

Add g_tls_connection_get_channel_binding_data call and enums

See merge request !1527

 * Add g_tls_connection_get_channel_binding_data API call
 * Add g_dtls_connection_get_channel_binding_data API call
 * Add get_binding_data method to GTlsConnection class
 * Add get_binding_data method to GDtlsConnection interface
 * Add GTlsChannelBindingType enum with tls-unique and
   tls-server-end-point types
 * Add GTlsChannelBindingError enum and G_TLS_CHANNEL_BINDING_ERROR
   quark
 * Add new API calls to documentation reference gio-sections-common

This speeds up the `cancellable` test a little by stopping waiting for
the threads to start up as soon as they have started, rather than after
an arbitrary timeout.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #1764

This makes no functional difference, but clarifies the code a little.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

This should fix some sporadic test failures in this test, although I
can’t be sure as I was unable to reproduce the original failure.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Closes: #1764

This makes sure the message gets formatted correctly and sent to the
right log file.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

It seems that allowing the GCancellable to be finalised in either the
main thread or the worker thread sometimes leads to crashes when running
on CI.

I cannot reproduce these crashes locally, and various analyses with
memcheck, drd and helgrind have failed to give any clues.

Fix this for this particular test case by deferring destruction of the
`GCancellable` instances until after the worker thread has joined.
That’s OK because this test is specifically checking a race between
`g_cancellable_cancel()` and disposal of a `GCancellableSource`.

The underlying bug remains unfixed, though, and I can only hope that we
eventually find a reliable way of reproducing it so it can be analysed
and fixed.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

guri: new URI parsing and generating functions

See merge request !1328

glib.supp: Suppress calloc() variant of g_get_charset()

Closes #2136

See merge request !1550

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #110

Add a set of new URI parsing and generating functions, including a new
parsed-URI type GUri. Move all the code from gurifuncs.c into guri.c,
reimplementing some of those functions (and
g_string_append_uri_encoded()) in terms of the new code.

Fixes:
#110Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

gmain: Access Unix signal handler state atomically

Closes #1670

See merge request !1297

Signed-off-by: Philip Withnall <withnall@endlessm.com>

Fixes: #2136

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>

(cherry picked from commit 8e7a483a)

Resolve "calling malloc in fork child is undefined-behaviour"

Closes #2140

See merge request !1544

Allocate a working buffer before calling `fork()` to avoid calling
`malloc()` in the async-signal-safe context between `fork()` and
`exec()`, where it’s not safe to use.

In this case, the buffer is used to assemble a wrapper around `argv` so
it can be run under `/bin/sh`.

See `man 7 signal-safety`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Fixes: #2140

Allocate a working buffer before calling `fork()` to avoid calling
`malloc()` in the async-signal-safe context between `fork()` and
`exec()`, where it’s not safe to use.

In this case, the buffer is used to assemble elements from `PATH` with
the binary from `argv[0]` to try executing them.

See `man 7 signal-safety`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #2140

Query the environment before calling `fork()` so that it doesn’t have to
be called in the async-signal-safe context between `fork()` and
`exec()`.

See `man 7 signal-safety`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #2140

They’re not safe to call in an async-signal-safe context on Linux.
`sysconf()` is safe to call on FreeBSD and OpenBSD (at least), so
continue doing that.

This will reduce performance in the (already low performance) fallback
case where `/proc` is inaccessible to a forked process on Linux, while
spawning a subprocess.

See `man 7 signal-safety`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #2140

Use the error handling infrastructure which already exists for other
failures in the async-signal-safe context.

`g_assert()` is unlikely to have caused problems in practice because it
is only async-signal-unsafe when the assertion condition fails.

See `man 7 signal-safety`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #2140

While `g_ascii_isdigit()` *is* currently async-signal-safe, it’s going
to be hard to remember to keep it that way if the implementation changes
in future.

It seems more robust to just reimplement it here, given that it’s not
much code.

See `man 7 signal-safety`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #2140

Use normal `close()` instead, which is guaranteed to be
async-signal-safe.

See `man 7 signal-safety`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #2140

Functions called between `fork()` and `exec()` have to be
async-signal-safe.

Add a comment to each function which is called in that context, and
`FIXME` comments to the non-async-signal-safe functions which end up
being called as leaves of the call graph.

The following commits will fix those `FIXME`s.

See `man 7 signal-safety`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Helps: #2140

tree: Fix various ableist language

See merge request !1546

gvalue: Do copy non-interned strings

Closes #2141

See merge request !1545

The G_VALUE_NOCOPY_CONTENTS for strings can only be used when collecting them
and not when copying them.

Instead only avoid copies for strings that are interned.

Fixes #2141

In almost all cases, rewording the documentation/comments made things
more specific and a little clearer.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

See: !1544 (comment 846645)

Various GLocalFile fixes related to the filesystem::remote attribute

See merge request !1534

There are two variables which are used to pass state from the Unix
signal handler interrupt function to the rest of `gmain.c`. They are
currently defined as `sig_atomic_t`, which means that they are
guaranteed to be interrupt safe. However, it does not guarantee they are
thread-safe, and GLib attaches its signal handler interrupt function to
a worker thread.

Make them thread-safe using atomics. It’s not possible to use locks, as
pthread mutex functions are not signal-handler-safe. In particular, this
means we have to be careful not to end up using GLib’s fallback atomics
implementation, as that secretly uses a mutex. Better to be unsafe than
have a re-entrant call into `pthread_mutex_lock()` from a nested signal
handler.

This commit solves two problems:
 1. Writes to `any_unix_signal_pending` and `unix_signal_pending` could
    be delivered out of order to the worker thread which calls
    `dispatch_unix_signals()`, resulting in signals not being handled
    until the next iteration of that worker thread. This is a
    performance problem but not a correctness problem.
 2. Setting an element of `unix_signal_pending` from
    `g_unix_signal_handler()` and clearing it from
    `dispatch_unix_signals_unlocked()` (in the worker thread) could
    race, resulting in a signal emission being cleared without being
    handled. That’s a correctness problem.
Signed-off-by: Philip Withnall <withnall@endlessm.com>

Fixes: #1670

The G_FILE_ATTRIBUTE_FILESYSTEM_REMOTE is set to TRUE only for NFS
filesystem types currently. Let's add also SMB filesystem types. This
also changes g_local_file_is_nfs_home function logic to handle only
NFS filesystems.

The g_local_file_is_remote function is misleading as it works only for
NFS filesystem types and only for locations in home directorly. Let's
rename it to g_local_file_is_nfs_home to make it obvious.

statfs/statvfs is called several times when querying filesystem info.
This is because the G_FILE_ATTRIBUTE_FILESYSTEM_REMOTE attribute is set
over is_remote_fs function, which calls statfs/statvfs again. Let's use
the already known fstype instead of redundant statfs/statvfs calls.
This also changes g_local_file_is_remote implementation to use
g_local_file_query_filesystem_info to obtain fstype, which allows to
remove duplicated code from is_remote_fs function.

Fix issue in GSocketAddressEnumerator documentation

Closes #1982

See merge request !1542

We should stop iterating the enumerator the first time it returns NULL,
even if error is set.

Fixes #1982

Signed-off-by: Philip Withnall <withnall@endlessm.com>

gsocket: Add missing check_socket() checks

Closes #1339

See merge request !1541