From f9c5815c132223139fc348166d861403e2196f47 Mon Sep 17 00:00:00 2001 From: Hans Boehm Date: Mon, 26 Feb 2018 23:45:24 +0300 Subject: 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. --- typd_mlc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'typd_mlc.c') 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(); -- cgit v1.2.1