The `gutils-user-database` test uses `LD_PRELOAD` to load
`getpwuid-preload.so`, which contains overrides for `getpwuid()`,
`getpwnam_r()` and `getpwuid_r()`. These overrides clear the `pw_name`
field to `NULL` to test handling of a weird error case from an old
systemd implementation of those functions (see !2244).
When running the `G_DISABLE_ASSERT` CI job, this test was crashing
without any debugging output. The `G_DISABLE_ASSERT` CI job runs its
tests under `--setup thorough`, which was the culprit here: the function
overrides in `getpwuid-preload.so` were being loaded (via `LD_PRELOAD`)
into the `bash` process which runs `thorough-test-wrapper.sh` and
causing it to crash.
Interestingly, this couldn’t be reproduced locally with a comparable
version of bash. Perhaps it depends on the CI machine’s environment,
triggering bash to make a `getpwuid()` (or similar) call which it
wouldn’t normally do locally.
So, slightly change `getpwuid-preload.so` to additionally link to
`libglib-2.0.so` and query `g_test_get_path()` to work out whether it’s
being called inside a unit test. If not, don’t modify the return value.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3272
The documentation in GLib of iconv is forgivably brief. Advanced users (e.g.
for streaming use, for which this API is recommended over the simpler GLib
APIs) will want to know more detail about what happens when there’s an
error: without knowing, you can’t really use this function for streaming.
Point to both iconv(3posix), which gives the fully-portable details, i.e.
all that a user of GLib can rely on, and iconv(3), which is rather easier to
read, and may be of interest to those writing GNU-specific code, or who know
that their GLib is built with libiconv.
The API already promises that it’s the “[s]ame as the standard UNIX routine
iconv()”, so it’s quite safe to point to the relevant man pages; looking at
the source code bears this out, as g_iconv merely calls iconv.
Cache the function pointer for g_datalist_id_update_atomic() in a static
variable in "gobject.c" to avoid looking it up repeatedly.
g_datalist_id_update_atomic() is anyway internal API. Like GData is not
a useful data structure in general, this function is only useful for
something specific inside GObject.
It can be easily seen that _local_g_datalist_id_update_atomic is never
read without having a GObject at hand (because we call it on
`&object->qdata`). Thus initializing the pointer in
g_object_do_class_init() (under lock) is sufficient to ensure
thread-safe initialization. Note that we still set the pointer via
g_atomic_pointer_set(). This is done in an attempt to pacify thread
sanatizer.
Note that also with LTO enabled, the GLIB_PRIVATE_CALL() call cannot be
inlined. Previously we get:
0000000000011300 <_weak_ref_set>:
...
1131d: e8 ee 03 ff ff call 1710 <glib__private__@plt>
11322: 8b 35 0c b2 05 00 mov 0x5b20c(%rip),%esi # 6c534 <quark_weak_locations.lto_priv.0>
11328: 4c 89 e1 mov %r12,%rcx
1132b: 49 8d 7c 24 10 lea 0x10(%r12),%rdi
11330: 48 8d 15 b9 42 ff ff lea -0xbd47(%rip),%rdx # 55f0 <weak_ref_data_get_or_create_cb.lto_priv.0>
11337: ff 90 80 00 00 00 call *0x80(%rax)
afterwards:
0000000000011300 <_weak_ref_set>:
...
1131d: 48 8d 7e 10 lea 0x10(%rsi),%rdi
11321: 48 89 f1 mov %rsi,%rcx
11324: 48 8d 15 c5 42 ff ff lea -0xbd3b(%rip),%rdx # 55f0 <weak_ref_data_get_or_create_cb.lto_priv.0>
1132b: 8b 35 0b b2 05 00 mov 0x5b20b(%rip),%esi # 6c53c <quark_weak_locations.lto_priv.0>
11331: ff 15 f9 b1 05 00 call *0x5b1f9(%rip) # 6c530 <_local_g_datalist_id_update_atomic.lto_priv.0>
Also note, that the point here is not to optimize _weak_ref_set() (which
is not a hot path). There is work in progress that will use
g_datalist_id_update_atomic() for more purposes (and during more
relevant code paths of GObject).
This documentation used to link to GLib’s TAP harness. However, the built-in
Automake support works fine, and is simpler to use. Hence, remove most of
the old documentation, and refer users to the Automake manual, adding just
one hint for use with GLib.
During "as-installed" testing, we should search the GIR_DIR for GIR XML,
instead of hard-coding that it is `${prefix}/share/gir-1.0`. This is
not the case on at least Debian, in order to make it possible to
install more than one architecture's flavour of `GLib-2.0.gir`,
which contains some architecture-specific `#define`s.
Also search GOBJECT_INTROSPECTION_DATADIR/GIR_SUFFIX (in practice
something like `/usr/share/gir-1.0` in all cases) to accommodate
distributions like Debian that move the architecture-independent
majority of GIR XML into /usr/share to avoid duplication, leaving
only the architecture-specific minority of files like `GLib-2.0.gir`
in the GIR_DIR.
Signed-off-by: Simon McVittie <smcv@collabora.com>
None of the users actually care about this parameter. And it's unlikely
that they ever will. Also, the passed "key_id" is the argument from
g_datalist_id_update_atomic(). If the caller really cared to know the
"key_id" in the callback, they could pass it as additional user data.
In some sense, it might be desirable to always initialize out parameters
to something.
However, this fallback index G_MAXUINT32 is not really useful for any
caller. That is, no caller can blindly access the index without checking
whether datalist_find() found (and returned) an entry.
Also, a caller cannot check for whether a entry was found via `if (idx
== G_MAXUINT32)`, because that theoretically is also a valid index.
The only sensible way to use datalist_find() is by accessing "idx"
if-and-only-if an entry was found. And all callers did that.
There is no point for initializing the value.
Uninitialized values can be even preferable over a non-useful
initialization to G_MAXUINT32, because if there is a buggy access them
under valgrind, there will be at least a warning.
The code comment was no longer correct. g_data_remove_internal() does
not depend on this anymore. It also just calls datalist_find(), which
searches the entire list.
The code comment was correct in the past, and how the code was then we
had to ensure the array is initialized.
This is no longer the case. We will only access the array at the indexes
from zero to up to (found_keys-1). And those places get always
initialized before we use them (as we increment found_keys at the same
time).
There is no longer a need to initialize this array to zero. Drop this.
Fixes: 3437414dd4f7 ('gdataset: use lookup index in g_datalist_id_remove_multiple()')
We use flags in both locked paths and in public ones (to check if a
source is destroyed or running), but those checks are not using atomic
logic, thus they lead to races in various tests.
Fix them by atomically change and read the values.
And this fixes various tests in thread sanitizer.
In g_source_ref() we can just ensure that the value we've referenced was
valid, instead of checking it before, since if get to such state the
GSource is broken anyways, but at least we can avoid doing an unneeded
atomic read.
Reason why we don't bother resetting the reference in case of failure.
If going from 1 -> 0 references failed, then we should restart the unref
process, by potentially re-entering in the dispose function again if
instead something else re-references us and we're going to drop the last
one again.
During g_source_unref() we might end up calling dispose from
multiple threads, and due to the ref/unref dance we were doing we could
end up initiating a GSource finalization while another thread was about
to revive the source.
This was because we were unreffing a source in a thread, and potentially
re-reffing it, at the same time, but it was not guaranteed that the
final decrement and test couldn't be followed by a further re-ref.
To avoid this, do not do any ref/unref/re-ref/re-unref dance while we're
about to dispose, but instead follow a bit more the g_object_unref()
logic, and start the disposal phase only if we're about to drop the last
reference, and only after the potential disposal call is done, we do an
actual ref count decrement, which may lead to the finalization or not.
We don't bother following the same logic at later point, since after
disposal we should really have just one thread running and revival of a
finalizing GSource isn't supported anyways.
With this logic we can also avoid doing unneeded context locking when
we've enough references on a GSource that disposal is unlikely to
happen.
Closes: #3612
It pulls in windows.h causing conflict for code that assume windows.h is not
previously included.
Thanks to Luca Bacci for proposing this fix, and @Osyotr for pointing
out this issue!
Fixes issue #3613.
This improves test coverage, adding coverage for some lines which I
spotted were not covered while testing the preceding commits.
It doesn’t directly test the preceding commits, though.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
For long input strings, it would have been possible for `i` to overflow.
Avoid that problem by using the `tz_length` instead, so that we count up
rather than down.
This commit introduces no functional changes (outside of changing
undefined behaviour), and can be verified using the identity
`i === length - tz_length`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
