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, 3 insertions, 2 deletions

diff --git a/malloc.c b/malloc.c
index 25ca72f7..0155fa5a 100644
--- a/malloc.c
+++ b/malloc.c
@@ -300,11 +300,12 @@ GC_API GC_ATTR_MALLOC void * GC_CALL GC_malloc_kind_global(size_t lb, int k)
     if (SMALL_OBJ(lb)) {
         void *op;
         void **opp;
-        size_t lg = GC_size_map[lb];
+        size_t lg;
         DCL_LOCK_STATE;
 
         GC_DBG_COLLECT_AT_MALLOC(lb);
         LOCK();
+        lg = GC_size_map[lb];
         opp = &GC_obj_kinds[k].ok_freelist[lg];
         op = *opp;
         if (EXPECT(op != NULL, TRUE)) {
@@ -365,8 +366,8 @@ GC_API GC_ATTR_MALLOC void * GC_CALL GC_generic_malloc_uncollectable(
         if (EXTRA_BYTES != 0 && lb != 0) lb--;
                   /* We don't need the extra byte, since this won't be  */
                   /* collected anyway.                                  */
-        lg = GC_size_map[lb];
         LOCK();
+        lg = GC_size_map[lb];
         opp = &GC_obj_kinds[k].ok_freelist[lg];
         op = *opp;
         if (EXPECT(op != NULL, TRUE)) {