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>
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>
