gio/tests/converter-stream.c: In function ‘test_expander’:
gio/tests/converter-stream.c:356:17: error: comparison of integer expressions of different signedness: ‘int’ and ‘long unsigned int’
356 | for (i = 0; i < sizeof(unexpanded_data); i++)
| ^
gio/tests/converter-stream.c: In function ‘test_compressor’:
gio/tests/converter-stream.c:445:17: error: comparison of integer expressions of different signedness: ‘int’ and ‘gsize’ {aka ‘long unsigned int’}
445 | for (i = 0; i < expanded_size; i++)
| ^
gio/tests/converter-stream.c:454:16: error: comparison of integer expressions of different signedness: ‘int’ and ‘gsize’ {aka ‘long unsigned int’}
454 | g_assert (i == expanded_size -1);
| ^~
gio/tests/converter-stream.c: In function ‘test_converter_pollable’:
gio/tests/converter-stream.c:1077:17: error: comparison of integer expressions of different signedness: ‘int’ and ‘gsize’ {aka ‘long unsigned int’}
1077 | for (i = 0; i < expanded_size; i++)
| ^
gio/tests/converter-stream.c:1086:16: error: comparison of integer expressions of different signedness: ‘int’ and ‘gsize’ {aka ‘long unsigned int’}
1086 | g_assert (i == expanded_size -1);
| ^~
gio/tests/converter-stream.c: In function ‘main’:
gio/tests/converter-stream.c:1220:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘long unsigned int’
1220 | for (i = 0; i < G_N_ELEMENTS (compressor_tests); i++)
| ^
gio/tests/converter-stream.c:1223:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘long unsigned int’
1223 | for (i = 0; i < G_N_ELEMENTS (truncation_tests); i++)
| ^
gio/tests/converter-stream.c:1226:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘long unsigned int’
1226 | for (i = 0; i < G_N_ELEMENTS (charset_tests); i++)
| ^
gio/tests/contenttype.c: In function ‘test_tree’:
gio/tests/contenttype.c:337:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘long unsigned int’
337 | for (i = 0; i < G_N_ELEMENTS (tests); i++)
| ^
gio/tests/contexts.c: In function ‘test_context_specific_emit’:
gio/tests/contexts.c:379:21: error: comparison of integer expressions of different signedness: ‘guint’ {aka ‘unsigned int’} and ‘gint32’ {aka ‘int’}
379 | for (i = 0; i < g_test_rand_int_range (1, 5); i++)
| ^
gio/tests/contexts.c:383:55: error: comparison of integer expressions of different signedness: ‘int’ and ‘guint’ {aka ‘unsigned int’}
383 | while (g_atomic_int_get (&observed_values[i]) != n)
| ^~
gio/tests/contexts.c:387:41: error: comparison of integer expressions of different signedness: ‘gint64’ {aka ‘long int’} and ‘guint64’ {aka ‘long unsigned int’}
387 | if (g_get_monotonic_time () > expiry)
| ^
1) Check that schedule_call_in_idle code branch of gdbusnamewatching.c
is working to call vanished handler in the thread which had watched the name
2) Check cancellation of vanished handler if the name is unwatched before
vanished callback is dispatched.
Closes#2011
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
`""` is not a valid path (`stat()` on it returns `ENOENT`). Previously,
a full `GLocalFile` was being created, which ended up resolving to
`$CWD`, through path canonicalisation. That isn’t right.
Fix it by creating a `GDummyFile` instead, and adding a unit test.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2328
Calling `dlopen()` with `libutil.so` makes the installed tests depend on
having glibc's development files installed. To avoid this, we can work
out the runtime library name at build time and `dlopen` that instead.
This approach is [taken from libfprint][1], thanks to Marco Trevisan.
[1]: f401f399a8
`ENXIO` can be returned from `open(2)` for special files (FIFOs, device
files and domain sockets) which are not backed by anything.
This fixes the error returned by `g_file_replace()` when trying to
replace such a file, so that it now matches the documentation.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
These test all the functionality and combinations of flags I can think
of. They do not cover dynamic behaviour (for example, what would happen
if the source file is deleted by another process part-way through a call
to `g_file_replace()`).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The `G_FILE_CREATE_REPLACE_DESTINATION` flag is equivalent to unlinking
the destination file and re-creating it from scratch. That did
previously work, but in the process the code would call `open(O_CREAT)`
on the file. If the file was a dangling symlink, this would create the
destination file (empty). That’s not an intended side-effect, and has
security implications if the symlink is controlled by a lower-privileged
process.
Fix that by not opening the destination file if it’s a symlink, and
adjusting the rest of the code to cope with
- the fact that `fd == -1` is not an error iff `is_symlink` is true,
- and that `original_stat` will contain the `lstat()` results for the
symlink now, rather than the `stat()` results for its target (again,
iff `is_symlink` is true).
This means that the target of the dangling symlink is no longer created,
which was the bug. The symlink itself continues to be replaced (as
before) with the new file — this is the intended behaviour of
`g_file_replace()`.
The behaviour for non-symlink cases, or cases where the symlink was not
dangling, should be unchanged.
Includes a unit test.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2325
Since a following commit is going to add a new test which references
Gitlab, so it’s best to move the URI bases inside the test cases.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
For non-Linux UNIX systems, the label 'close_libutil:' in
'test_pollable_unix_pty()' will have no statement that goes with that
label. Just do a 'return' on non-Linux UNIX systems.
Expand an existing unit test to check that the target FD of a
`g_subprocess_launcher_take_fd()` call doesn’t get closed when
`g_subprocess_launcher_close()` is called. Only the source FD should be
closed by the parent process.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2332
Swedish as spoken in El Salvador is not listed in
/usr/share/i18n/SUPPORTED, and in any case is probably not what we meant.
A more plausible language code would be Swedish as spoken in Sweden.
Prompted by improving the Debian packaging of GLib to generate most of
the language codes mentioned in the tests, so that we can have better
test coverage.
Signed-off-by: Simon McVittie <smcv@collabora.com>
It’s not feasible to test that the require-same-user flag can cause
authentication to fail, as that would require the build environment to
have two users available. We can, however, test that it passes when
authenticating a client and server running under the same user account.
I have manually tested that the new flag works, by running the following
as user A:
```
`$prefix/gdbus-daemon --print-env &`
gdbus call --session --dest org.freedesktop.DBus --object-path /org/freedesktop/DBus --method org.freedesktop.DBus.ListNames
```
And then running the `gdbus call` command again as user B (with the same
value for `DBUS_SESSION_BUS_ADDRESS` in the environment), which
produces:
```
Error connecting: Unexpected lack of content trying to read a line
```
(an authentication rejection)
Commenting out the use of
`G_DBUS_SERVER_FLAGS_AUTHENTICATION_REQUIRE_SAME_USER` from
`gdbusdaemon.c`, the `gdbus call` command succeeds for both users.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The GDBusConnectionFlags and GDBusServerFlags can affect how we carry
out authentication and authorization, either making it more or less
restrictive, so it's desirable to "fail closed" if a program is compiled
against a new version of GLib but run against an old version.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Convert all the call sites which use `g_memdup()`’s length argument
trivially (for example, by passing a `sizeof()`), so that they use
`g_memdup2()` instead.
In almost all of these cases the use of `g_memdup()` would not have
caused problems, but it will soon be deprecated, so best port away from
it.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2319
Various tests have leaks where it isn't clear whether the data is
intentionally not freed, or leaked due to a bug. If we mark these
tests as TODO, we can skip them under AddressSanitizer and get the
rest to pass, giving us a baseline from which to avoid regressions.
Signed-off-by: Simon McVittie <smcv@collabora.com>
AddressSanitizer, UndefinedBehaviourSanitizer and probably others
involve adding instrumentation into the code under test, which doesn't
go well with LD_PRELOAD modules that absolutely need to be
self-contained.
Signed-off-by: Simon McVittie <smcv@collabora.com>
We format the message into a string twice, once for each byte-order,
but only return the one corresponding to the last byte-order to the
caller. This means we need to free the first one.
Signed-off-by: Simon McVittie <smcv@collabora.com>
- use watcher auto start flag.
- use watch_name_on_connection_with_closures.
- use an existing service name for auto start.
Closes#2011
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
Where the early call to g_socket_set_option() fails because of
check_socket() failing due to `inited` still being FALSE.
This brings 634b692 back into working order, by fixing the regression
introduced in 39f047e.
Co-authored-by: Ole André Vadla Ravnås <oleavr@gmail.com>
These two APIs are useful to publish an object which path content is not
controlled (e.g. dynamically built or coming from external source).
Closes#968
(Rebased and tweaked by Frederic Martinsons)
Signed-off-by: Frederic Martinsons <frederic.martinsons@sigfox.com>
This makes the tests a whole lot closer to being valgrind-clean, and
revealed a few legitimate memory leaks in amongst the noise caused by
keeping the singleton GSettingsBackend around for the lifetime of the
process.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Split out XDG_CURRENT_DESKTOP handling to a separate function and make
sure that it drops all the invalid entries properly. Earlier a bad
entry could slip through the checks by sitting just after another bad
entry, like in env being set to `invalid1!:invalid2!`, where
`invalid2!` could slip the checks.
It occasionally fails in CI with output like:
```
196/274 glib:gio / gdbus-connection-slow FAIL 0.54 s (killed by signal 6 SIGABRT)
--- command ---
G_TEST_BUILDDIR='/builds/pwithnall/glib/_build/gio/tests' G_TEST_SRCDIR='/builds/pwithnall/glib/gio/tests' GIO_MODULE_DIR='' /builds/pwithnall/glib/_build/gio/tests/gdbus-connection-slow
--- stdout ---
\# random seed: R02S4eb186e89e2472eedd11538b37192543
1..2
\# Start of gdbus tests
\# Start of connection tests
Bail out! GLib-GIO:ERROR:../gio/tests/gdbus-connection-slow.c:98:test_connection_flush: assertion failed (error == NULL): Child process killed by signal 11 (g-exec-error-quark, 19)
--- stderr ---
**
GLib-GIO:ERROR:../gio/tests/gdbus-connection-slow.c:98:test_connection_flush: assertion failed (error == NULL): Child process killed by signal 11 (g-exec-error-quark, 19)
cleaning up pid 12991
```
which is not very helpful. Add some more debug output to print the
stdout and stderr of the child process, to hopefully give an insight
into why it’s dying with signal 11 (sigsegv).
I can’t reproduce the sigsegv locally.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
- When querying a TCP socket, getsockopt() may succeed but the resulting
`optlen` will be zero. This means we'd previously be reading
uninitialized stack memory in such cases.
- After a file-descriptor has gone through FD-passing, getsockopt() may
fail with EINVAL. At least this is the case with TCP sockets.
- While at it also use SOL_LOCAL instead of hard-coding its value.
These variables were already (correctly) accessed atomically. The
`volatile` qualifier doesn’t help with that.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #600
And drop the `volatile` qualifier from the variables, as that doesn’t
help with thread safety.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #600
http://isvolatileusefulwiththreads.in/c/
It’s possible that the variables here are only marked as volatile
because they’re arguments to `g_once_*()`. Those arguments will be
modified in a subsequent commit.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #600
These tests were originally written using the output directly from a
fuzzer which had triggered the bugs we’re testing for. However, that
means they’re liable to no longer test what they’re intended to test if
the `GDBusMessage` parsing code is changed to (for example) check for
certain errors earlier in future.
It’s better to only have one invalidity in each binary blob, so change
the test messages to all be valid apart from the specific thing they’re
testing for.
The changes were based on reading the D-Bus specification directly:
https://dbus.freedesktop.org/doc/dbus-specification.html
During these changes I found one problem in
`test_message_parse_deep_header_nesting()` where it wasn’t actually
nesting variants in the header deeply enough to trigger the bug it was
supposed to be testing for. Fixed that.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #1963
This commit is the unmodified results of running
```
black $(git ls-files '*.py')
```
with black version 19.10b0. See #2046.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This incidentally also exercises the intended pattern for sending fds in
a D-Bus message: the fd list is meant to contain exactly those fds that
are referenced by a handle (type 'h') in the body of the message, with
numeric handle value n corresponding to g_unix_fd_list_peek_fds(...)[n].
Being able to send and receive file descriptors that are not referenced by
a handle (as in OpenFile here) is a quirk of the GDBus API, and while it's
entirely possible in the wire protocol, other D-Bus implementations like
libdbus and sd-bus typically don't provide APIs that make this possible.
Reproduces: https://gitlab.gnome.org/GNOME/glib/-/issues/2074
Signed-off-by: Simon McVittie <smcv@collabora.com>
This test ensures that g_socket_client_connect_to_host_async() fails if
it is cancelled, but it's not cancelled until after 1 millisecond. Our
CI testers are hitting that race window, and Milan is able to reproduce
the crash locally as well. Switching it from 1ms to 0ms is enough for
Milan to avoid the crash, but not enough for our CI, so let's move the
cancellation to a GSocketClientEvent callback where the timing is
completely deterministic.
Hopefully fixes#2221
By default, when using g_subprocess_launcher_take_fd() to pass an
FD to a child, the GSubprocessLauncher object also takes ownership
of the FD in the parent, and closes it during finalize(). This is
a reasonable assumption in the majority of the cases, but sometimes
it isn't a good idea.
An example is when creating a GSubprocessLauncher in JavaScript:
here, the destruction process is managed by the Garbage Collector,
which means that those sockets will remain opened for some time
after all the references to the object has been droped. This means
that it could be not possible to detect when the child has closed
that same FD, because in order to make that work, both FDs
instances (the one in the parent and the one in the children) must
be closed. This can be a problem in, as an example, a process that
launches a child that communicates with Wayland using an specific
socket (like when using the new API MetaWaylandClient).
Of course, it isn't a valid solution to manually call close() in
the parent process just after the call to spawn(), because the FD
number could be reused in the time between it is manually closed,
and when the object is destroyed and closes again that FD. If that
happens, it will close an incorrect FD.
One solution could be to call run_dispose() from Javascript on the
GSubprocessLauncher object, to force freeing the resources.
Unfortunately, the current code frees them in the finalize()
method, not in dispose() (this is fixed in !1670 (merged) ) but it
isn't a very elegant solution.
This proposal adds a new method, g_subprocess_launcher_close(),
that allows to close the FDs passed to the child. To avoid problems,
after closing an FD with this method, no more spawns are allowed.
Fix: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1677
Expose a function that prepares an attribute query string to be passed
to g_file_query_info() to get a list of attributes normally copied with
the file. This function is used by the implementation of
g_file_copy_attributes, and it's useful if one needs to split
g_file_copy_attributes into two stages, for example, when nautilus does
a recursive move of a directory. When files are moved from the source
directory, its modification time changes. To preserve the mtime on the
destination directory, it has to be queried before moving files and set
after doing it, hence these two stages.
Signed-off-by: Maxim Mikityanskiy <maxtram95@gmail.com>
The previous parsing code could read off the end of a URI if it had an
incorrect %-escaped character in.
Fix that, and more closely implement parsing for the syntax defined in
RFC 6874, which is the amendment to RFC 3986 which specifies zone ID
syntax.
This requires reworking some network-address tests, which were
previously treating zone IDs incorrectly.
oss-fuzz#23816
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
This doesn't trigger the cancellation assertion issue when run locally
(the task didn't return yet, so the error is simply overwritten), but
perhaps it ever does in CI. Anyhow, it's good to have a cancellation
test.
This currently just implements the same functionality as the existing
`stat()`/`fstat()`/`fstatat()`/`lstat()` calls, although where a reduced
field set is requested it may return faster.
Helps: #1970
* 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 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
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>
This was mostly machine generated with the following command:
```
codespell \
--builtin clear,rare,usage \
--skip './po/*' --skip './.git/*' --skip './NEWS*' \
--write-changes .
```
using the latest git version of `codespell` as per [these
instructions](https://github.com/codespell-project/codespell#user-content-updating).
Then I manually checked each change using `git add -p`, made a few
manual fixups and dropped a load of incorrect changes.
There are still some outdated or loaded terms used in GLib, mostly to do
with git branch terminology. They will need to be changed later as part
of a wider migration of git terminology.
If I’ve missed anything, please file an issue!
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Some editors automatically remove trailing blank lines, or
automatically add a trailing newline to avoid having a trailing
non-blank line that is not terminated by a newline. To avoid unrelated
whitespace changes when users of such editors contribute to GLib,
let's pre-emptively normalize all files.
Unlike more intrusive whitespace normalization like removing trailing
whitespace from each line, this seems unlikely to cause significant
issues with cherry-picking changes to stable branches.
Implemented by:
find . -name '*.[ch]' -print0 | \
xargs -0 perl -0777 -p -i -e 's/\n+\z//g; s/\z/\n/g'
Signed-off-by: Simon McVittie <smcv@collabora.com>
This ensures that we do really export the symbols for Visual
Studio-style builds, by using _GLIB_EXTERN to decorate the generated
prototypes and including config.h so that we are sure the symbols are
actually exported.
Sometimes this test was timing out due to the file monitor notifications
taking longer than the arbitrary 2s delay before ending the test and
checking its results at the end of `iclosed_cb()`.
Avoid that timing-dependence by ending the test when the expected file
monitor notifications are seen, or after a 10s timeout (if so, the test
is failed).
This makes the test run 4× faster in the normal case, as it’s no longer
waiting for a timeout to elapse if the file monitor notifications come
in sooner.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The test added for #1841 spawned 100000 threads. That was fine on a
desktop machine, but on a heavily loaded CI machine, it could result in
large (and unpredictable) slowdowns, resulting in the test taking over
120s in about 1 in 5 runs, and hence failing that CI pipeline due to a
timeout. When passing normally on CI, the test would take around 90s.
Here’s a histogram of time per iteration on a failing (timed out) test
run. Each iteration is one thread spawn:
Iteration duration (µs) | Frequency
------------------------+----------
≤100 | 0
100–200 | 30257
200–400 | 13696
400–800 | 1046
800–1000 | 123
1000–2000 | 583
2000–4000 | 3779
4000–8000 | 4972
8000–10000 | 1027
10000–20000 | 2610
20000–40000 | 650
40000–80000 | 86
80000–100000 | 10
100000–200000 | 2
>200000 | 0
There’s no actual need for the test to spawn 100000 threads, so rewrite
it to reuse a single thread, and pass new data to that thread.
Reverting the original commit (e4a690f5dd) reproduces the failure on
100 out of 100 test runs with this commit applied, so the test still
works.
The test now takes 3s, rather than 11s, to run on my computer, and has
passed when run with `meson test --repeat 1000 cancellable`.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
When multiple tests were run in parallel, this would race on its access
to `~/.dbus-keyrings` to authenticate with the D-Bus server, since the
keyring directory was not appropriately sandboxed to the unit test.
Use `G_TEST_OPTION_ISOLATE_DIRS` to automatically isolate each unit
test’s directory usage.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1954
Commit 721e385 left one remaining race in the filter test, with a
comment associated with it. Unfortunately, the (seemingly unrelated)
changes in #1841 to `GCancellable` seem to have made this remaining race
a lot more likely to fail on FreeBSD than before.
What’s likely to have happened (although I was unable to reproduce the
failure, due to not having a FreeBSD system; I was only able to
reproduce the problem as a 3/1000 failure on Linux, which is still worth
fixing) is that the atomic write of the `FilterData.serial` to be
expected by the filter function sometimes happened after the filter
function had executed, so the expected message was dropped and didn’t
result in an update to the `FilterData` state.
Rework the test so that instead of setting some expectations (on
`FilterData`) in one thread and then checking them in another thread,
the worker thread just unconditionally returns messages from the filter
function to the main thread, and then the main thread checks whether the
expected one has been filtered.
With this change applied, the `gdbus-connection` test passes 5000 times
in a row for me, on Linux; and doesn’t seem to fail any more on the
FreeBSD CI machines over a few runs. (Previously it failed on 4/5 runs.)
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #2092Fixes: #1957
The GIO tests memory-monitor-dbus and memory-monitor-portal use a number
of third party Python modules that may not be present when running the
test case.
Instead of failing due to missing imports, catch the ImportError and
mock a test case that skips. This can't use the usual unittest.skip
logic because the test case class itself uses a 3rd party module.
Closes#2083.
There are two memory monitor tests that use Python's unittest module directly,
but GLib tests should be outputting TAP. Use the embedded TAPTestRunner to
ensure that TAP is output for these tests too.
