Log MALLOC_PERTURB_ so glibc corruption aborts are reproducible

The value is random per run and was never surfaced, so a run that aborts
on heap corruption couldn't be replayed with the same perturb byte.

Author: jbachorik

build-logic/conventions/src/main/kotlin/com/datadoghq/profiler/ProfilerTestPlugin.kt

@@ -214,8 +214,12 @@ class ProfilerTestPlugin : Plugin<Project> {
                 !PlatformUtils.isMusl() &&
                 !testEnv.containsKey("LD_PRELOAD")
             ) {
+                val perturbByte = (1..255).random()
                 put("MALLOC_CHECK_", "3")
-                put("MALLOC_PERTURB_", (1..255).random().toString())
+                put("MALLOC_PERTURB_", perturbByte.toString())
+                // Logged so a glibc-detected corruption abort can be reproduced with the
+                // same perturb byte (the value is otherwise random per run).
+                project.logger.lifecycle("[$configName] MALLOC_PERTURB_=$perturbByte")
             }
             putAll(testEnv)
             put("DDPROF_TEST_DISABLE_RATE_LIMIT", "1")

utils/run-chaos-harness.sh

@@ -160,6 +160,9 @@ case $ALLOCATOR in
     # malloc, not the LD_PRELOAD-replaced allocators below.
     export MALLOC_CHECK_=3
     export MALLOC_PERTURB_=$((RANDOM % 255 + 1))
+    # Logged so a glibc-detected corruption abort can be reproduced with the
+    # same perturb byte (the value is otherwise random per run).
+    echo "MALLOC_PERTURB_=${MALLOC_PERTURB_}"
     # thread-churn/dump-storm/vthread-context-cascade cycle many short-lived
     # threads; glibc's per-thread arenas are slow to trim back to the OS,
     # which was inflating container RSS past the OOM limit on aarch64