This doesn’t introduce any functional changes, but should make the code
a little clearer.
Drive-by improvements while trying to debug #1264.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1264
This introduces no functional changes, but makes it a little clearer how
the ownership of these `GDBusMessage` instances works. The free function
is changed to `g_clear_object()` to avoid the possibility of somehow
using the messages after freeing them.
Basically just some drive-by docs improvements while trying to debug
issue #1264.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1264
This didn’t actually cause any observable bugs, since the structures of
`PropertyData` and `PropertyGetAllData` were equivalent for the members
which the free function touches.
Definitely should be fixed though.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This appears to fix an intermittent failure seen when sending a D-Bus
message with either of a cancellable or a timeout set.
In particular, I can reliably reproduce it with:
```
meson test gdbus-test-codegen-min-required-2-64 --repeat 10000
```
It can be caught easily with asan when reproduced. Tracking down the
location of the refcount mismatch was a little tricky, but was
simplified by replacing a load of `g_object_ref (message)` calls with
`g_dbus_message_copy (message, NULL)` to switch `GDBusMessage` handling
to using copy semantics. This allowed asan to home in on where the
refcount mismatch was happening.
The problem was that `send_message_data_deliver_error()` takes ownership
of the `GTask` passed to it, but the
`send_message_with_replace_cancelled_idle_cb()` and
`send_message_with_reply_timeout_cb()` functions which were calling it,
were not passing in a strong reference as they should have.
Another approach to fixing this would have been to change the transfer
semantics of `send_message_data_deliver_error()` so it was `(transfer
none)` on its `GTask`. That would probably have resulted in cleaner
code, but would have been a lot harder to verify/review the fix, and
easier to inadvertently introduce new bugs.
The fact that the bug was only triggered by the cancellation and timeout
callbacks explains why it was intermittent: these code paths are
typically never hit, but the timeout path may sometimes be hit on a very
slow test run.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #1264
mkstemp-like family of functions also use g_open () under the hood so
they should pass the O_CLOEXEC flag there for race-free setting of the
close-on-exec flag.
setmntent () call uses the same mode flag set as fopen (), so it should
also include the "e" mode flag for race-free setting of the close-on-exec
flag.
All Unix CRTs examined: glibc, musl, BSDs, Apple libc, Android bionic
ignore unknown fopen () mode flags, so this flag can be added
unconditionally for Unix builds.
Only Windows CRT is intolerant of these, so the single case in
g_dbus_address_connect () where the fopen () call is shared between Unix
and Windows needs appropriate platform-specific handling.
Skipped the call sites in libcharset and xdgmime copylibs.
The `equal_func` closure can already have all required information
available without the item, and passing the item via the closure instead
of an explicit parameter is more natural for languages that have a
concept of closures that can capture variables.
Otherwise, the content of the buffer is thrown away when switching
from reading via a GDataInputStream to unbuffered reads when waiting
for the "BEGIN" line.
(The code already tried to protect against over-reading like this by
using unbuffered reads for the last few lines of the auth protocol,
but it might already be too late at that point. The buffer of the
GDataInputStream might already contain the "BEGIN" line for example.)
This matters when connecting a sd-bus client directly to a GDBus
client. A sd-bus client optimistically sends the whole auth
conversation in one go without waiting for intermediate replies. This
is done to improve performance for the many short-lived connections
that are typically made.
This reverts commit 27bee8fe5d.
Inevitably, despite testing the CI multiple times before merging commit
27bee8fe, the CI is now failing again in the `socket` test due to (what
I continue to assume is) the kernel regression:
https://gitlab.gnome.org/martinpitt/glib/-/jobs/2585332
In order to unblock development on `main` expediently, I guess I’ll just
revert the revert.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Reopens: #2879
It’s not meant to be exposed publicly yet (we’re not ready to stabilise
it), but it was incorrectly decorated with `GLIB_AVAILABLE_IN_2_76`.
We can’t remove the decorator and use it that way, as it’s called in
libgio, so we have to expose it using `GLIB_PRIVATE_CALL()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2876
Don’t just set them when they’re true and rely on their non-presence
being evaluated to `FALSE`. That means that they erroneously don’t get
returned in `g_file_info_list_attributes()`.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2907
`g_file_info_get_is_hidden()` should not be called without checking the
attribute is set first, just as with the calls higher up in this code.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2907
As documented in a previous commit, these functions should not be called
without the right attributes being present in the `GFileInfo`. Add
critical warnings to make this more obvious.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2907
It doesn’t make sense to (for example) call `g_file_info_get_name()` if
the `GFileInfo` doesn’t contain `G_FILE_ATTRIBUTE_STANDARD_NAME`, given
that building the `GFileInfo` is typically a static process and entirely
under the control of the programmer.
By being this restrictive, we avoid having to return ‘unknown’ values
for some of these standard APIs, particularly the numeric ones such as
`g_file_info_get_size()`. If APIs like that were to work correctly in
the face of a `GFileInfo` without `G_FILE_ATTRIBUTE_STANDARD_SIZE`
specified, they’d have to be able to return a value to indicate the
attribute is missing. Returning `0` or `G_MAXSIZE` to indicate that
would be ambiguous.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2907
Since gmodule-visibility.h is now a custom target and produced at
buildtime, it might not always exist in time for use in other source
files. This was the case for gio-inotify.
Add it as an additional source file to ensure in-time generation.
Currently, inbuf_size and outbuf_size are not documented as not
nullable, but they are expected to be so, which might lead to unexpected
crashes. Moreover, outbuf itself is also expected to not be null, so
this commit adds the appropriate GI annotations and early returns on
failed preconditions.
LLVM objcopy's --strip-all is more aggressive that GNU objcopy --strip-all
and will remove everything that is not actually used. In this case we
see the following error:
`error: 'gio/tests/test_resources.o': Symbol table has link index of 5 which is not a valid index`
Fix this by only removing debug symbols instead of all unused symbols and
sections.
Helps: https://gitlab.gnome.org/GNOME/glib/-/issues/2720
Unlike GNU ld which has a default target architecture, ld.lld is always a
cross-linker and has the same behaviour for all targets. If you don't tell
ld.lld what the target architecture is it can't infer the right ELF flags
for the resulting object file.
```
$ ~/cheri/output/sdk/bin/ld -r -b binary gio/tests/test5.gresource -o gio/tests/test_resources.o -v
LLD 14.0.0 (compatible with GNU linkers)
ld: error: target emulation unknown: -m or at least one .o file required
```
As you can see from the error message it can't infer the target
architecture (you need a least one valid .o file or the -m flag).
If you use the compiler instead of directly invoking the linker it will
pass the appropriate flags:
```
$ ~/cheri/output/sdk/bin/clang -r -Wl,-b,binary gio/tests/test5.gresource -o gio/tests/test_resources.o -v
clang version 14.0.0 (https://github.com/CTSRD-CHERI/llvm-project.git ff66b683475fc44355b2010dbcbe1202d785e6f8)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/alexrichardson/cheri/output/sdk/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/10
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/11
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/12
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/12
Candidate multilib: .;@m64
Selected multilib: .;@m64
"/home/alexrichardson/cheri/output/sdk/bin/ld" --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o gio/tests/test_resources.o -L/usr/lib/gcc/x86_64-linux-gnu/12 -L/usr/lib/gcc/x86_64-linux-gnu/12/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/home/alexrichardson/cheri/output/sdk/bin/../lib -L/lib -L/usr/lib -r -b binary gio/tests/test5.gresource
❯ file gio/tests/test_resources.o
gio/tests/test_resources.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
```
This works for most architectures, but ones that need additional metadata
sections to encode the used ABI, etc. will require a different approach
using .incbin. However, that is a change for another MR.
Partially fixes: https://gitlab.gnome.org/GNOME/glib/-/issues/2720
In case the OS does not support epoll and kqueue, we get the warning:
gio/tests/pollable.c: In function ‘test_pollable_unix_nulldev’:
gio/tests/pollable.c:266:7: warning: unused variable ‘fd’
[-Wunused-variable]
266 | int fd;
Get rid of it.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Now that there is g_string_free_and_steal (), we can use it instead of
the older g_string_free (_, FALSE). Make sure to use its return value
while doing so, as opposed to manually accessing string->str, to avoid
compiler warnings and make the intent more explicit.
This is all done in preparation for making g_string_free (_, FALSE) warn
on unused return value much like g_string_free_and_steal (), which will
happen in the next commit.
Signed-off-by: Sergey Bugaev <bugaevc@gmail.com>
Spawning a process correctly is a lot more complicated than just bunging
an argument onto the return value from this function.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2901
Fix the tests, by allocating the structure.
==121338==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffe44018610 at pc 0x00000040ff71 bp 0x7ffe440178f0 sp 0x7ffe440178e8
READ of size 8 at 0x7ffe44018610 thread T0
#0 0x40ff70 in test_launch_uris_with_terminal ../gio/tests/desktop-app-info.c:1393
#1 0x7efd97b831e8 in test_case_run ../glib/gtestutils.c:2947
#2 0x7efd97b831e8 in g_test_run_suite_internal ../glib/gtestutils.c:3037
#3 0x7efd97b82d23 in g_test_run_suite_internal ../glib/gtestutils.c:3056
#4 0x7efd97b82d23 in g_test_run_suite_internal ../glib/gtestutils.c:3056
#5 0x7efd97b82d23 in g_test_run_suite_internal ../glib/gtestutils.c:3056
#6 0x7efd97b84189 in g_test_run_suite ../glib/gtestutils.c:3136
#7 0x7efd97b842c5 in g_test_run ../glib/gtestutils.c:2248
#8 0x4055bc in main ../gio/tests/desktop-app-info.c:1901
#9 0x7efd9564a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)
#10 0x7efd9564a5c8 in __libc_start_main_alias_1 (/lib64/libc.so.6+0x275c8)
#11 0x4059f4 in _start (/home/elmarco/src/gnome/glib/build/gio/tests/desktop-app-info+0x4059f4)
Address 0x7ffe44018610 is located in stack of thread T0 at offset 128 in frame
#0 0x404d1f in main ../gio/tests/desktop-app-info.c:1823
This frame has 6 object(s):
[48, 52) 'argc' (line 1821)
[64, 72) 'path' (line 1870)
[96, 104) 'argv' (line 1822)
[128, 144) '<unknown>' <== Memory access at offset 128 is inside this variable
[160, 176) '<unknown>'
[192, 288) 'supported_terminals' (line 1825)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
There’s a kernel bug on the CI machines which is causing this test to
fail all the time and it’s getting my goat.
The test can be re-enabled later (by reverting this commit) when the
kernel on the CI VM host is fixed. I don’t know when that’s going to
happen.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2879
Otherwise if, for whatever reason, the `app` loses its D-Bus name,
`g_application_quit()` is called from `name_was_lost()` before it’s
called from `quit_already()`, and then `quit_already()` does an invalid
read on `app`.
If the name was not meant to be lost at this point in the test, the
subsequent `g_assert_false (name_lost)` will catch that, so this change
shouldn’t cause the test to pass unnecessarily.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
