[PATCH] D74567: [scudo][standalone] Workaround for full regions on Android

Kostya Kortchinsky via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 13 09:28:59 PST 2020


cryptoad created this revision.
cryptoad added reviewers: pcc, eugenis, cferris, hctim, morehouse.
Herald added projects: Sanitizers, LLVM.
Herald added a subscriber: Sanitizers.

Due to Unity, we had to reduce our region sizes, but in some rare
situations, some programs (mostly tests AFAICT) manage to fill up
a region for a given size class.

So this adds a workaround for that attempts to allocate the block
from the immediately larger size class, wasting some memory but
allowing the application to keep going.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D74567

Files:
  compiler-rt/lib/scudo/standalone/combined.h


Index: compiler-rt/lib/scudo/standalone/combined.h
===================================================================
--- compiler-rt/lib/scudo/standalone/combined.h
+++ compiler-rt/lib/scudo/standalone/combined.h
@@ -267,6 +267,17 @@
       bool UnlockRequired;
       auto *TSD = TSDRegistry.getTSDAndLock(&UnlockRequired);
       Block = TSD->Cache.allocate(ClassId);
+      // If the allocation failed, the most likely reason with a 64-bit primary
+      // is the region being full. In that event, retry once using the
+      // immediately larger class (except if the failing class was already the
+      // largest). This will waste some memory but will allow the application to
+      // not fail.
+      if (SCUDO_ANDROID && SCUDO_CAN_USE_PRIMARY64) {
+        if (UNLIKELY(!Block)) {
+          if (ClassId < SizeClassMap::LargestClassId)
+            Block = TSD->Cache.allocate(++ClassId);
+        }
+      }
       if (UnlockRequired)
         TSD->unlock();
     } else {


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D74567.244460.patch
Type: text/x-patch
Size: 988 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20200213/ef5450e8/attachment.bin>


More information about the llvm-commits mailing list