Avoid potential race when accessing size_map table

There is again a data race between GC_extend_size_map and GC_size_map[]
readers, though it is again not likely to fail in practice.

It is feasible to just move all of the GC_size_map accesses under the
lock, and this does not look to incur a substantial penalty.

* gcj_mlc.c (GC_gcj_malloc, GC_gcj_malloc_ignore_off_page): Move
lg=GC_size_map[lb] to be right after LOCK() instead of preceding it.
* malloc.c (GC_malloc_kind_global, GC_generic_malloc_uncollectable):
Likewise.
* typd_mlc.c (GC_malloc_explicitly_typed_ignore_off_page): Likewise.
* include/gc.h (GC_get_size_map_at): Update comment to note that the
client should use synchronization when calling the function.
* include/private/gc_priv.h (_GC_arrays._size_map): Add comment about
synchronization.

1 files changed, 1 insertions, 1 deletions

diff --git a/typd_mlc.c b/typd_mlc.c
index 0092547f..e7df05b3 100644
--- a/typd_mlc.c
+++ b/typd_mlc.c
@@ -621,8 +621,8 @@ GC_API GC_ATTR_MALLOC void * GC_CALL
     lb = SIZET_SAT_ADD(lb, TYPD_EXTRA_BYTES);
     if (SMALL_OBJ(lb)) {
         GC_DBG_COLLECT_AT_MALLOC(lb);
-        lg = GC_size_map[lb];
         LOCK();
+        lg = GC_size_map[lb];
         op = GC_eobjfreelist[lg];
         if (EXPECT(0 == op, FALSE)) {
             UNLOCK();