Spotted by ASAN during the tests:
Direct leak of 72 byte(s) in 1 object(s) allocated from:
#0 0x7ff0b4562077 in calloc (/lib64/libasan.so.8+0xba077)
#1 0x7ff0b3e8b508 in g_malloc0 ../glib/gmem.c:155
#2 0x7ff0b375052f in g_closure_new_simple ../gobject/gclosure.c:220
#3 0x7ff0b375b422 in g_cclosure_new ../gobject/gclosure.c:976
#4 0x7ff0b37d159e in g_signal_group_connect_full ../gobject/gsignalgroup.c:790
#5 0x7ff0b37d159e in g_signal_group_connect ../gobject/gsignalgroup.c:886
#6 0x4045d8 in test_signal_group_invalid ../gobject/tests/signalgroup.c:331
#7 0x7ff0b3f369a5 in test_case_run ../glib/gtestutils.c:2930
#8 0x7ff0b3f369a5 in g_test_run_suite_internal ../glib/gtestutils.c:3018
#9 0x7ff0b3f364ed in g_test_run_suite_internal ../glib/gtestutils.c:3035
#10 0x7ff0b3f364ed in g_test_run_suite_internal ../glib/gtestutils.c:3035
#11 0x7ff0b3f37879 in g_test_run_suite ../glib/gtestutils.c:3112
#12 0x7ff0b3f37995 in g_test_run ../glib/gtestutils.c:2231
#13 0x40253c in main ../gobject/tests/signalgroup.c:664
#14 0x7ff0b2de758f in __libc_start_call_main (/lib64/libc.so.6+0x2d58f)
Direct leak of 72 byte(s) in 1 object(s) allocated from:
#0 0x7f012addf077 in calloc (/lib64/libasan.so.8+0xba077)
#1 0x7f012a708508 in g_malloc0 ../glib/gmem.c:155
#2 0x7f0129fcd52f in g_closure_new_simple ../gobject/gclosure.c:220
#3 0x7f0129fd8422 in g_cclosure_new ../gobject/gclosure.c:976
#4 0x7f012a04e5ae in g_signal_group_connect_full ../gobject/gsignalgroup.c:791
#5 0x7f012a04e5ae in g_signal_group_connect ../gobject/gsignalgroup.c:887
#6 0x4043cc in test_signal_group_invalid ../gobject/tests/signalgroup.c:308
#7 0x7f012a7b39a5 in test_case_run ../glib/gtestutils.c:2930
#8 0x7f012a7b39a5 in g_test_run_suite_internal ../glib/gtestutils.c:3018
#9 0x7f012a7b34ed in g_test_run_suite_internal ../glib/gtestutils.c:3035
#10 0x7f012a7b34ed in g_test_run_suite_internal ../glib/gtestutils.c:3035
#11 0x7f012a7b4879 in g_test_run_suite ../glib/gtestutils.c:3112
#12 0x7f012a7b4995 in g_test_run ../glib/gtestutils.c:2231
#13 0x40253c in main ../gobject/tests/signalgroup.c:664
#14 0x7f012966458f in __libc_start_call_main (/lib64/libc.so.6+0x2d58f)
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
==24477==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7ffde020de20 at pc 0x7f2e6f6413f1 bp 0x7ffde020c9d0 sp 0x7ffde020c180
READ of size 4101 at 0x7ffde020de20 thread T0
#0 0x7f2e6f6413f0 in __interceptor_strlen.part.0 (/lib64/libasan.so.8+0x4c3f0)
#1 0x7f2e6ef4abee in g_build_path_va ../glib/gfileutils.c:1908
#2 0x7f2e6f085956 in g_test_build_filename_va ../glib/gtestutils.c:4294
#3 0x7f2e6f086684 in g_test_build_filename ../glib/gtestutils.c:4365
#4 0x403a33 in test_search_path_heap_allocation ../glib/tests/spawn-path-search.c:422
#5 0x7f2e6f0839a5 in test_case_run ../glib/gtestutils.c:2930
#6 0x7f2e6f0839a5 in g_test_run_suite_internal ../glib/gtestutils.c:3018
#7 0x7f2e6f0834ed in g_test_run_suite_internal ../glib/gtestutils.c:3035
#8 0x7f2e6f084879 in g_test_run_suite ../glib/gtestutils.c:3112
#9 0x7f2e6f084995 in g_test_run ../glib/gtestutils.c:2231
#10 0x40145f in main ../glib/tests/spawn-path-search.c:488
#11 0x7f2e6e31258f in __libc_start_call_main (/lib64/libc.so.6+0x2d58f)
#12 0x7f2e6e312648 in __libc_start_main_alias_1 (/lib64/libc.so.6+0x2d648)
#13 0x401524 in _start (/home/elmarco/src/gnome/glib/build/glib/tests/spawn-path-search+0x401524)
Address 0x7ffde020de20 is located in stack of thread T0 at offset 4256 in frame
#0 0x40387f in test_search_path_heap_allocation ../glib/tests/spawn-path-search.c:401
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The raw value is escaped according to D-Bus rules. This is probablematic
for Windows backslashed paths. We can use URI unescaping, it seems
that's what gdbusaddress.c is doing too.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The AF_UNIX API is available under all platforms since 2.71.1, and
credentials functions returns NOT_SUPPORTED error appropriately,
we can thus remove the special-casing for !unix.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
The "/unix-fd/scm" test is quite Unix-specific, the next patch is going
to add a portable test.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This bug only gets triggered on BSD, because it calls `recv_message()`
with `G_IO_HUP | G_IO_IN`. That takes two code paths in
`recv_message()`, and ends up calling `shutdown_source()` twice. The
second call causes a critical warning.
Fixes: https://gitlab.gnome.org/GNOME/glib/-/jobs/2004192
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The runner machine is offline and there is no ETA on when it will be
back, so disable the CI job which uses it for now so that pipelines
can proceed.
See https://gitlab.gnome.org/Infrastructure/GitLab/-/issues/558
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Check the spawn implementation behaviour when the stderr is a
socket (mostly for win32).
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Used in following commits, including in some GIO experiments, so make it
a private API.
For now, this implementation is similar to the glib/gspawn-win32.c one,
with mroe error checking and better on error behaviour. A following
patch will also fix the case of duplicating sockets.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Use a prefix matching the binary, rename the test "scm", as it involves
SocketControlMessage.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
This encodes what GLib is already bound by, as it’s hosted on
gitlab.gnome.org, which is GNOME infrastructure and hence bound by the
GNOME code of conduct.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
