The test case will fail with the
g_assert_false (g_subprocess_get_successful (proc));
assert failing. Without the fix, it'll hit sometimes, but rather
unreliably. When running `meson test --repeat 100`, it'll reproduce
anywhere between the first or much later, but mostly before the 20th
iteration on my system.
Helps: #3071
We might repeatedly get si_pid == 0 for a child that hasn't exited,
meaning we won't get a correct exit status. This seems to happen when
the glib application tracks a ptrace():ed child process; the correct
exit status of the process using e.g. a BPF program, where one can
observe that glib appears to get it wrong.
Fixes: #3071
While it's only called one time, this is something that can only happen
during the function call, so it's more correct to mark it as call scope,
so that bindings don't have to wait for the callback invocation to
cleanup the data.
As per commit 5d738ddc some callbacks are not nullable anymore even
though they should be.
This breaks the introspection as some arguments won't be considered
nullable anymore.
You can notice this in https://gitlab.gnome.org/3v1n0/gjs/-/pipelines/558839
where some some tests are running against stable g-i version and others
(the failing ones) against the devel one.
Currently, when adding new elements to GTree we blindly increment the node
counter, which is only of guint size (so 32-bit even on 64-bit Unix
platforms).
This is even more problematic because the only way to check whether
particular GTree is empty is to check whether its node count is zero.
This will obviously give wrong answer if this counter overflows.
Let's fix this by adding an appropriate check when adding a new node.
For the recently added g_tree_{insert,replace}_node () API we can simply
return NULL in such case.
However, the older g_tree_{insert,replace} () API doesn't have any ability
to return an error so for them we follow the example of
g_ptr_array_extend () and g_ptr_array_set_size () by calling g_error ()
when this happens.
Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
g_tree_nnodes () is returning a signed integer type (gint), however the
tree node counter value type is really an unsigned integer (guint).
This means that the returned size will be negative if the container holds
more than G_MAXINT elements.
Add a note to this function that its return value can be cast back to
guint in order to support its full range of values.
This will also make sure that we take this into account in future Glib
versions.
Signed-off-by: Maciej S. Szmigiero <maciej.szmigiero@oracle.com>
It's not safe to use setlocale() to mutate the locale in a threaded
program. Lots of other tests still do this, and I'm not putting in the
effort to fix them comprehensively in the absense of actual failures on
CI, but I figured it'd be good to fix the tests that I was touching.
This definitely does not do anything on Linux. I bet it's not needed on
other platforms, either. It's unsafe and may crash; there is no safe way
to mutate the environment in threaded programs.
This is a copy of the existing test_l10n, modified to use LC_TIME
instead of LC_MESSAGES. It's not safe as each call to g_setenv() or
setlocale() could cause the test to crash; there is no safe way to
change a threaded process's environment, and a threaded process's locale
can only be safely changed using uselocale(), not with setlocale().
The calls to g_setenv() are definitely not needed on Linux. I wonder
whether removing these will break the test on other platforms?
The calls to setlocale() should be replaced by a dance of
uselocale() -> duplocale() -> newlocale() -> uselocale() on Linux. But
this is not portable and this is a cross-platform test. We would have to
make the test platform-specific to do this. macOS and at least FreeBSD
provide these functions via xlocale.h, but this isn't portable.
It's supposed to be possible to translate settings values using LC_TIME
rather than LC_MESSAGES to determine which translation to use, but
Sebastian Keller noticed that it's not working properly. I've
implemented his proposed solution, which is to actually temporarily
change LC_MESSAGES to match LC_TIME for just as long as necessary to
force gettext to use the desired message catalog.
Fixes#2575
Fix typo in gio/gappinfo (duplicated word)
Fix typo in gio/gtlsdatabase.c (duplicated word)
Fix typo in gio/gapplication.c (duplicated word, previous words rearranged to improve readability)
Fix typo in glib/tests/gvariant.c (duplicated word)
Fix typo in glib/win_iconv.c (duplicated word)
Fix typo in gio/gschema.dtd (meaning, missing letter)
Fix typo in gio/gdbusintrospection.c (duplicated word)
Fix typo in gio/gdbusintrospection.c (duplicated word).
As commit 44616ebafd ('gmain: More explicitly document
g_main_context_release() prereqs') correctly notes, you need to have the
context acquired before releasing it (just like a ref must match an
unref).
Commit 3926af723a ('gmain: Add precondition assertions to
g_main_context_release()') then goes one step further, and requires that
the calling thread is also the owner (the thread, that acquired the
context).
This is something which has been documented by g_main_context_release()
for years:
> Releases ownership of a context previously acquired **by this thread**
With acquire/release and g_main_context_is_owner() we track the thread
that acquired the context. That is mainly useful for asserting
correctness to not accessing the context from an unexpected thread.
Note that g_main_context_acquire() returns FALSE and does nothing when
the context is already acquired from another thread. Methods like
g_main_context_{prepare,query,dispatch}() require that the calling
thread is the owner (although, they don't assert for that, which they
maybe should).
With the assertion, it means you cannot pass an acquired context to
another thread for release. Obviously, if you pass on an acquired
context to another thread, the only next thing you can do is
g_main_context_release() (no acquire,prepare,query,dispatch). But it's
still useful to be able to release it, and to be able to keep it
acquired for a prolonged time.
libnm needs that, as it integrates a GMainContext into another
GMainContext. For that, it needs to acquire the inner context and keep
it acquired for as long as the context is integrated. Otherwise, when a
source gets attached to the inner context, the inner context is not
woken up (see g_source_attach_unlocked()). In commit e26a8a5981 ('Add
G_MAIN_CONTEXT_FLAGS_OWNERLESS_POLLING'), a flag was introduced to solve
that same problem, without keeping the inner context acquired all the
time. Note that G_MAIN_CONTEXT_FLAGS_OWNERLESS_POLLING is a flag of the
GMainContext, so it only works if the user who integrates the inner
context also controls how the context was created. For libnm, having
the inner context acquired at all times is no problem, because it's
understood that the user gives up agency on the inner context while it's
integrated. The only thing to consider is that the outer context might
be iterated on another thread. When calling prepare,query,dispatch on
the inner context, the code will notice it, release the inner context
and re-acquire it on the new thread ([1]). This works just fine, but it
requires that g_main_context_release() works from any thread.
So, in order to not break NetworkManager, let’s drop the ownership
assertion. However, NetworkManager is strictly breaking the API contract
here, and GLib reserves the right to re-add this assertion in future.
Still keep the assertion for the owner_count.
(Commit and commit message significantly updated by Philip Withnall; all
errors are his.)
[1] 9f01cff04f/src/libnm-glib-aux/nm-shared-utils.c (L4944)
Related: 3926af723a ('gmain: Add precondition assertions to g_main_context_release()')
Related: c67dd9d3fe ('gmain: Add a missing return on error path in g_main_context_release()')
Closes#3054
There’s no reason that anyone can think of that this should be
disallowed. It’s useful for language runtimes like GJS to be able to
find out the allocation size of dynamic GObjects.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #623
This reverts commit 252bbcd207.
After further discussion in !3511, we’ve decided that there are risks
associated with this change, and it’s not the best way of addressing the
original problem.
The original motivation for the change turned out to be that
`-mms-bitfields` was not handled by `windres`, which was receiving it
from `pkg-config --cflags glib-2.0` in some projects. However, if
`windres` is claiming to accept CFLAGS then it should accept (and
ignore) `-mms-bitfields`, since the `-m` family of options are defined
in `man gcc`, just like `-I`, `-D`, etc.
There is some question that there might still be third party projects
which are built with an old enough compiler that `-mms-bitfields` is not
the compiler default. For that reason, we should either still continue
to specify `-mms-bitfields` in the `.pc` file, or add a test to assert
that third party projects are always compiled with `-mms-bitfields` set.
But adding a new test for all third-party compilations is risky (if we
get it wrong, things will break; and it’s a test which may behave
differently on different platforms), so it seems safer to just keep
`-mms-bitfields` in `.pc` for now.
Once all compilers which we require specify `-mms-bitfields` by default,
we can finally drop this flag (without adding a test for third-party
compilations).
See: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3511
The old name was not quite correct: the part of a URI which is just past
the scheme might be the hostname or the path. It isn’t necessarily just
a path.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
