[PATCH] D70761: scudo: Reverse order of testing sizes for realloc.

[Peter Collingbourne via Phabricator via llvm-commits]

pcc created this revision.
pcc added reviewers: cryptoad, hctim, eugenis.
Herald added projects: Sanitizers, LLVM.
Herald added a subscriber: Sanitizers.
pcc added a child revision: D70762: scudo: Add initial memory tagging support..

This test was previously effectively doing:
P = malloc(X); write X bytes to P; P = realloc(P, X - Y); P = realloc(P, X)
and expecting that all X bytes stored to P would still be identical after
the final realloc.

This happens to be true for the current scudo implementation of realloc,
but is not guaranteed to be true by the C standard ("Any bytes in the new
object beyond the size of the old object have indeterminate values.").
This implementation detail will change with the new memory tagging support,
which unconditionally zeros newly allocated granules when memory tagging is
enabled. Fix this by reversing the order in which we test sizes, so that
we don't end up following this pattern.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D70761

Files:
  compiler-rt/lib/scudo/standalone/tests/combined_test.cpp


Index: compiler-rt/lib/scudo/standalone/tests/combined_test.cpp
===================================================================
--- compiler-rt/lib/scudo/standalone/tests/combined_test.cpp
+++ compiler-rt/lib/scudo/standalone/tests/combined_test.cpp
@@ -117,7 +117,7 @@
   // class size maps.
   P = Allocator->allocate(DataSize, Origin);
   memset(P, Marker, DataSize);
-  for (scudo::sptr Delta = -32; Delta < 32; Delta += 8) {
+  for (scudo::sptr Delta = 32; Delta > -32; Delta -= 8) {
     const scudo::uptr NewSize = DataSize + Delta;
     void *NewP = Allocator->reallocate(P, NewSize);
     EXPECT_EQ(NewP, P);


-------------- next part --------------
A non-text attachment was scrubbed...
Name: D70761.231166.patch
Type: text/x-patch
Size: 622 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20191127/3b3c463f/attachment.bin>