gclosure: fix ATOMIC_CHANGE_FIELD to read vint atomically

Depending on luck, g_closure_ref may access closure->vint and observe
different values between reads. This manifests as a test failure in
signals-refcount{2,4}, properties-refcount1, and closure-refcount depending
on timing and re-runs.

Jakub Jelinek analysed this on GCC bug PR119607 after I'd reported it
over there as a possible GCC regression.

The critical part being g_closure_ref -> ATOMIC_INC_ASSIGN -> ATOMIC_CHANGE_FIELD
where closure->vint gets re-read repeatedly, both outside and inside the retry
loop. To fix that:

1. Atomically fetch it the first time;
2. Use the cached read, not a fresh read, of vint in the loop;
3. Use g_atomic_int_compare_and_exchange_full in the loop so we get a freshly
cached vint if it changed in another thread.

Bug: https://gcc.gnu.org/PR119607
Fixes: 834ddd19 ('turned all modifications to the first 32 integer bits in a closure into')
Co-authored-by: Jakub Jelinek <jakub@redhat.com>
This commit is contained in:
Sam James
2025-04-03 19:03:27 +01:00
committed by Philip Withnall
parent eaa7e5bdfd
commit 190d6d3a91

View File

@@ -110,15 +110,17 @@ typedef union {
G_STMT_START { \
ClosureInt *cunion = (ClosureInt*) _closure; \
gint new_int, old_int, success; \
old_int = g_atomic_int_get (&cunion->vint); \
do \
{ \
ClosureInt tmp; \
tmp.vint = old_int = cunion->vint; \
tmp.vint = old_int; \
_SET_OLD tmp.closure._field; \
tmp.closure._field _OP _value; \
_SET_NEW tmp.closure._field; \
new_int = tmp.vint; \
success = g_atomic_int_compare_and_exchange (&cunion->vint, old_int, new_int); \
success = g_atomic_int_compare_and_exchange_full (&cunion->vint, old_int, new_int,\
&old_int); \
} \
while (!success && _must_set); \
} G_STMT_END