In function ‘memmem_with_end_pointer’,
inlined from ‘domain_found’ at ../glib/gmessages.c:2695:16,
inlined from ‘should_drop_message’ at ../glib/gmessages.c:2802:35:
../glib/gmessages.c:2674:19: warning: ‘log_domain_length’ may be used
uninitialized [-Wmaybe-uninitialized]
2674 | #define my_memmem memmem
| ^
../glib/gmessages.c:2683:10: note: in expansion of macro ‘my_memmem’
2683 | return my_memmem (haystack, (const char *) haystack_end - (const char *) haystack, needle, needle_len);
| ^~~~~~~~~
../glib/gmessages.c: In function ‘should_drop_message’:
../glib/gmessages.c:2760:13: note: ‘log_domain_length’ was declared here
2760 | gsize log_domain_length;
| ^~~~~~~~~~~~~~~~~
If a value has no size, we'd end up to use g_variant_store() with a NULL
value, and this is not allowed by the API, leading to errors:
stderr:
../glib/gvariant-core.c:1429:9: runtime error: null pointer passed as argument
1, which is declared to never be null
#0 0x7f9c139ce559 in g_variant_store ../glib/gvariant-core.c:732
#1 0x7f9c13c60b01 in g_variant_byteswap ../glib/gvariant.c:6211
#2 0x564ae412e9b9 in test_byteswap ../glib/tests/gvariant.c:2321
#3 0x564ae412e9b9 in test_byteswaps ../glib/tests/gvariant.c:2374
#4 0x7f9c13bc1000 in test_case_run ../glib/gtestutils.c:3115
#5 0x7f9c13bc1000 in g_test_run_suite_internal ../glib/gtestutils.c:3210
#6 0x7f9c13bc0d7b in g_test_run_suite_internal ../glib/gtestutils.c:3229
#7 0x7f9c13bc0d7b in g_test_run_suite_internal ../glib/gtestutils.c:3229
#8 0x7f9c13bc2019 in g_test_run_suite ../glib/gtestutils.c:3310
#9 0x7f9c13bc216f in g_test_run ../glib/gtestutils.c:2379
#10 0x564ae410f326 in main ../glib/tests/gvariant.c:6045
In case data is NULL we ended up to call memcpy with NULL parameter
which is undefined behavior (see the trace below).
So instead of having multiple null checks to do just the same, simplify
the NULL or 0-sized cases.
../glib/gbytes.c:140:7: runtime error: null pointer passed as argument 2,
which is declared to never be null
#0 0x7f56ea7c667e in g_bytes_new ../glib/gbytes.c:140
#1 0x5557c3659f06 in test_null ../glib/tests/bytes.c:453
#2 0x7f56ea9c0f70 in test_case_run ../glib/gtestutils.c:3115
#3 0x7f56ea9c0f70 in g_test_run_suite_internal ../glib/gtestutils.c:3210
#4 0x7f56ea9c0ceb in g_test_run_suite_internal ../glib/gtestutils.c:3229
#5 0x7f56ea9c1f89 in g_test_run_suite ../glib/gtestutils.c:3310
#6 0x7f56ea9c20df in g_test_run ../glib/gtestutils.c:2379
#7 0x5557c36599d2 in main ../glib/tests/bytes.c:536
Ensure we don't do an user-after-free access, as reported by ASAN:
==3704==ERROR: AddressSanitizer: stack-use-after-return on address
0x70a58f8631c0 at pc 0x000000405144 bp 0x7fffff62c7a0 sp 0x7fffff62c798
READ of size 4 at 0x70a58f8631c0 thread T0
#0 0x405143 in on_object_unregistered ../../GNOME/glib/gio/tests/gdbus-export.c:597
#1 0x70a592e858d8 in call_destroy_notify_data_in_idle ../../GNOME/glib/gio/gdbusconnection.c:244
#2 0x70a5940016a4 in g_idle_dispatch ../../GNOME/glib/glib/gmain.c:6221
#3 0x70a59401095b in g_main_dispatch ../../GNOME/glib/glib/gmain.c:3348
#4 0x70a59401095b in g_main_context_dispatch_unlocked ../../GNOME/glib/glib/gmain.c:4197
#5 0x70a59401ba17 in g_main_context_iterate_unlocked ../../GNOME/glib/glib/gmain.c:4262
#6 0x70a59401cc73 in g_main_context_iteration ../../GNOME/glib/glib/gmain.c:4327
#7 0x405658 in test_threaded_unregistration_iteration ../../GNOME/glib/gio/tests/gdbus-export.c:1878
#8 0x405658 in test_threaded_unregistration ../../GNOME/glib/gio/tests/gdbus-export.c:1952
#9 0x70a5940dfb04 in test_case_run ../../GNOME/glib/glib/gtestutils.c:2988
#10 0x70a5940dfb04 in g_test_run_suite_internal ../../GNOME/glib/glib/gtestutils.c:3090
#11 0x70a5940df893 in g_test_run_suite_internal ../../GNOME/glib/glib/gtestutils.c:3109
#12 0x70a5940df893 in g_test_run_suite_internal ../../GNOME/glib/glib/gtestutils.c:3109
#13 0x70a5940e0bc9 in g_test_run_suite ../../GNOME/glib/glib/gtestutils.c:3189
#14 0x70a5940e0d1f in g_test_run ../../GNOME/glib/glib/gtestutils.c:2275
#15 0x40eb72 in session_bus_run ../../GNOME/glib/gio/tests/gdbus-sessionbus.c:69
#16 0x403a2c in main ../../GNOME/glib/gio/tests/gdbus-export.c:1990
#17 0x70a591d9f149 in __libc_start_call_main (/lib64/libc.so.6+0x28149) (BuildId: 0d710e9d9dc10c500b8119c85da75004183618e2)
#18 0x70a591d9f20a in __libc_start_main_impl (/lib64/libc.so.6+0x2820a) (BuildId: 0d710e9d9dc10c500b8119c85da75004183618e2)
#19 0x403b44 in _start (/tmp/_build/gio/tests/gdbus-export+0x403b44) (BuildId: f6312e919c3d94e4c49270b0dfc5c870e1ba550b)
Address 0x70a58f8631c0 is located in stack of thread T0 at offset 192 in frame
#0 0x40525f in test_threaded_unregistration ../../GNOME/glib/gio/tests/gdbus-export.c:1936
This frame has 7 object(s):
[32, 40) 'local_error' (line 1835)
[64, 72) 'unregister_thread' (line 1836)
[96, 104) 'value' (line 1838)
[128, 136) 'value_str' (line 1839)
[160, 168) 'call_result' (line 1840)
[192, 204) 'object_registration_data' (line 1834) <== Memory access at offset 192 is inside this variable
[224, 240) 'data' (line 1833)
This is what we already ignored with valgrind and it's something that
we should always ignore since it's leaked by design.
So do explicitly mark it as such.
See the previous commit. Clarify these variable names so it’s more
obvious they contain a size in bytes rather than a length in wide-chars.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3649
It can be confusing otherwise when getting string values: is the size in
bytes or wide-characters?
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Helps: #3649
`value_size` is in bytes, whereas `ms_resource_prefix_len` is in wide
characters, so they cannot be compared directly. This meant that if
12 ≤ `value_size` < 24 then the call to `memcmp()` would read off the
end of `value`.
Fix it by using a wide-character and nul-aware comparison function and
operating only on wide-lengths. This is safe because
`g_win32_registry_key_get_value_w()` guarantees that string-typed return
values are nul-terminated.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3649
This can happen if a user passes a ludicrously long string to argv.
Spotted by chamalsl as #YWH-PGM9867-48.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This ensures they’re not writing files to the build directory, which
avoids race conditions when running multiple invocations of the tests.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It’s not currently needed, because the filename being passed to the
subprocess is hard-coded and doesn’t contain anything which would need
escaping. But the following commit is going to change that (to avoid
filename collisions), so let’s fix the quoting first.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This ensures they’re not writing files to the build directory, which
avoids race conditions when running multiple invocations of the tests.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
So the filename we delete at the end of the test is definitely the same
one we created at the start of the test.
This introduces no functional changes, but will make a refactor in the
following commit simpler.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This ensures they’re not writing files to the build directory, which
avoids race conditions when running multiple invocations of the tests.
This is not entirely trivial, because the tests for
`g_key_file_load_from_data_dirs()` are affected by the overridden
`$XDG_DATA_HOME` directory. Mitigate that by copying the file they want
to that directory (and relying on `G_TEST_OPTION_ISOLATE_DIRS` to delete
it again afterwards).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Today I learned that it magically turns `-` into `/` to search
subdirectories for key files. Turns out that wasn’t documented at all.
i.e. it’ll search for `$datadir/some-key-file.ini` and, if that’s not
found, will then try `$datadir/some/key-file.ini` and then
`$datadir/some/key/file.ini`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Rather than creating files in the current directory. This is a bit
neater, and avoids races between parallel invocations of the unit tests
if the file names aren’t guaranteed to be unique (e.g. by using
`g_mkstemp()`).
Add `G_TEST_OPTION_ISOLATE_DIRS` too, to make sure we use a unique
subdirectory of `g_get_tmp_dir()`. This means that paths like
`g_get_tmp_dir() / some-file` are guaranteed to be race-free even if the
filename is not unique, because the test tmp dir now is.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
In the `g-file-info-filesystem-readonly` test.
This doesn’t introduce any functional changes, but makes the code a
little easier to read (because the parts of the path are now in
hierarchical order) and makes it a bit clearer that we’re building a
path rather than an arbitrary string.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Otherwise it’s easy to assume that they create a file in the system
temporary directory, if they’re only called with a filename template
(without a path).
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
It’s not entirely clear from the documentation, but `g_mkstemp()` (and
`g_mkdtemp()`) operate in the current directory, rather than the system
temporary directory.
This meant these tests were all writing files to the build directory.
This is messy, though thankfully not a correctness issue or a race
because `g_mkstemp()` guarantees to return a unique file for each
caller.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
This probably wasn’t causing any problems since it was a self-contained
read only access of a non-existent path. But it’s a bit tidier to
contain this all inside `/tmp`.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
