Fix data race regarding *rlh value in generic_malloc_many

(a cherry-pick of commit dcaad0211 from 'master')

The issue was highlighted in GC_generic_malloc_many() by a static code
analysis tool as "using an unreliable value of *rlh inside the second
locked section; if the data that *rlh depends on was changed by
another thread, this use might be incorrect".

* mallocx.c (GC_generic_malloc_many): Do not increment rlh by lg (use
rlh[lg] instead); reload rlh value after
acquiring the GC lock (at the end of the loop).

1 files changed, 5 insertions, 3 deletions

diff --git a/mallocx.c b/mallocx.c
index 9e93c707..77d284ad 100644
--- a/mallocx.c
+++ b/mallocx.c
@@ -349,10 +349,9 @@ GC_API void GC_CALL GC_generic_malloc_many(size_t lb, int k, void **result)
         struct hblk * hbp;
         hdr * hhdr;
 
-        rlh += lg;
-        while ((hbp = *rlh) != 0) {
+        while ((hbp = rlh[lg]) != NULL) {
             hhdr = HDR(hbp);
-            *rlh = hhdr -> hb_next;
+            rlh[lg] = hhdr -> hb_next;
             GC_ASSERT(hhdr -> hb_sz == lb);
             hhdr -> hb_last_reclaimed = (unsigned short) GC_gc_no;
 #           ifdef PARALLEL_MARK
@@ -416,6 +415,9 @@ GC_API void GC_CALL GC_generic_malloc_many(size_t lb, int k, void **result)
                 /* GC lock is needed for reclaim list access.   We      */
                 /* must decrement fl_builder_count before reacquiring   */
                 /* the lock.  Hopefully this path is rare.              */
+
+                rlh = ok -> ok_reclaim_list; /* reload rlh after locking */
+                if (NULL == rlh) break;
               }
 #           endif
         }