Commit 084e1d868 added a preallocation to an array to avoid
reallocations later on, but neglected the fact that after N insertions
into the array, there’s always a NULL terminator added to the end. Fix
the preallocation to include that NULL terminator.
This doesn’t change the correctness of the code, but should eliminate
one reallocation.
Spotted by Sebastian Dröge. See
https://gitlab.gnome.org/GNOME/glib/merge_requests/674.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
res_ninit() requires the __res_state struct passed to it to be
zero-filled on FreeBSD.
Spotted and analysed by Ashish SHUKLA.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes#1697
There are some cases where valgrind turns up leaks that are already
suppressed in the file, but with a slight difference at the top of the
stack. Add suppressions for these cases as well.
Synchronize access to cancelled flag of cancellable, which was
previously access without synchronization in g_cancellable_is_cancelled.
Use atomic operations instead of existing global mutex, to avoid
serializing calls to g_cancellable_is_cancelled across all threads.
Ensure that source is attached to the context before it migth be used
from another thread, since otherwise operation on source are
unsynchronized and not thread-safe.
In particular there was a data race between g_source_attach and
g_source_set_ready_time (used from g_file_monitor_source_handle_event).
GValue g_type field is used for synchronization with g_once_init_enter,
and so it should be written to only with g_once_init_leave.
Replace structure copy with memcpy that copies the one remaining field
of GValue, i.e., data array.
This essentially reverts commit
cffed58737.
The preceding two commits have fixed the test so it’s no longer flaky.
The following command gives 5000 passes in a row for me:
meson test -C /opt/gnome/build/glib/ socket-service --repeat 5000
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Fixes: #1679
It’s occasionally possible for the cancellation of the service to happen
before connection_cb() gets scheduled in the other thread. The
locking/unlocking order of mutex_712570 requires:
• test_threaded_712570(): lock mutex
• test_threaded_712570(): start wait loop
• connection_cb(): lock mutex
• test_threaded_socket_service_finalize(): unlock mutex
• test_threaded_712570(): end wait loop
• test_threaded_712570(): unlock mutex
Fix that by quitting the main loop once connection_cb() has been called
(i.e. once the server thread has received the incoming connection
request), rather than just after the client thread (main thread) has
sent a connection request.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1679
On about 1 in 3 test runs, the socket-service would fail with the
ref_count assertion in connection_cb() failing (the ref_count would be 3
rather than the expected 2).
This was happening because the GTask from
g_socket_listener_accept_socket_async() now always takes at least one
main context iteration to return a result (whereas before
6f3d57d2ee it might have taken zero), but
the ref_count can drop below 3 before the process of returning a result
starts. During the process of returning a result, the ref_count
temporarily increases again, which is what was breaking the test.
Fix this by waiting for one more main context iteration. This is a bit
of a hack, but the real fix would be to expose the outstanding_accept
boolean from GSocketService as public API (which the test can
interrogate), and that seems too much like exposing internal state.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1679
Almost everything that needs gioenumtypes.h also needs
gobjectenumtypes.h. Fixes:
ccache cc @gio/win32/gio@win32@@giowin32@sta/gwin32filemonitor.c.obj.rsp
In file included from ../gio/win32/gwin32filemonitor.h:25:0,
from ../gio/win32/gwin32filemonitor.c:26:
../glib/glib-object.h:37:10: fatal error: gobject/gobjectenumtypes.h: No such file or directory
#include <gobject/gobjectenumtypes.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
GIO modules built with MSVC do not begin with 'lib', but they can
begin with 'gio'. Without this, you can only load GIO modules built
with MSVC that are `name.dll`, not `gioname.dll`.
Compilers get confused when variables are initialized by a function by
taking them as reference in an out argument; this, coupled with the fact
that C does not initialize variables by default, most commonly results
in a "maybe uninitialized" compiler warning.
512e9b3b34 added a call to schedule_pending_close() in the read
callback after the reference to the worker is already gone. In case this was
the last reference to the worker this resulted in a use-after-free.
6f3d57d2ee made this more likely to happen because on connection close
the worker cancel action is now async while the reference to the worker
gets dropped right away.
Move the call to schedule_pending_close() before the unref.
Fixes#1686
