fix(profiler): avoid canary+LR corruption in start_routine_wrapper_spec

On musl/aarch64/JDK11, DEOPT PACKING corrupts the top ~224 bytes of the
thread stack, which is exactly where start_routine_wrapper_spec's frame
lives. Two crashes can result:

- struct Cleanup triggers -fstack-protector-strong canary insertion;
  DEOPT corrupts it; epilogue fires __stack_chk_fail.
- After the canary, 'return' loads the corrupted saved LR and jumps
  to a garbage address.

Fix: no_stack_protector suppresses the canary; pthread_exit() replaces
'return' so LR is never used. Cleanup is done explicitly via TLS
(ProfiledThread::currentTid()) before pthread_exit.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

Author: jbachorik

ddprof-lib/src/main/cpp/libraryPatcher_linux.cpp

@@ -86,27 +86,45 @@ static void init_tls_and_register() {
 // 1. Register the newly created thread to profiler
 // 2. Call real start routine
 // 3. Unregister the thread from profiler once the routine is completed.
-// This version is to workaround a precarious stack guard corruption,
-// which only happens in Linux/musl/aarch64/jdk11
-__attribute__((visibility("hidden")))
+// This version works around stack corruption observed on musl/aarch64/JDK11:
+//
+// Empirical observation (hs_err analysis): after DEOPT PACKING fires on a
+// thread running compiled lambda$measureContention$0 at sp=0x...49d0, this
+// wrapper's frame (sp=0x...5020, ~144 bytes below thread stack top) shows a
+// corrupted FP (odd address 0x...5001) and a corrupted stack canary.  The
+// corruption is confined to the top ~224 bytes of the stack (the region between
+// DEOPT PACKING sp and the thread stack top).  The mechanism is the same
+// "precarious stack guard corruption" the noinline helpers above already
+// defend against for SignalBlocker's sigset_t.
+//
+// Two symptoms arise from this corruption:
+//
+// (a) Stack-canary crash: -fstack-protector-strong inserts a canary whenever
+//     the frame has a non-trivially destructed local (e.g. a Cleanup struct).
+//     That canary lands in the corruption zone; the epilogue fires
+//     __stack_chk_fail.  no_stack_protector removes the canary.
+//
+// (b) Corrupted-LR crash: even without a canary, `return` loads the saved LR
+//     from the corrupted frame and jumps to a garbage address.  pthread_exit()
+//     terminates the thread without using LR.  HotSpot on musl returns normally
+//     from java_start (no forced-unwind), so no exception-based cleanup path
+//     is needed.
+//
+// Cleanup reads tid from TLS (via ProfiledThread::currentTid()) rather than
+// from a stack variable, so it is correct even after the frame is corrupted.
+__attribute__((visibility("hidden"), no_stack_protector))
 static void* start_routine_wrapper_spec(void* args) {
     RoutineInfo* thr = (RoutineInfo*)args;
     func_start_routine routine = thr->routine();
     void* params = thr->args();
     delete_routine_info(thr);
     init_tls_and_register();
-    // RAII cleanup: reads tid from TLS in the destructor to avoid storing any
-    // state on this frame — on musl/aarch64/JDK11 the JVM corrupts this wrapper's
-    // stack frame during routine(params), so any int stored here would be garbage.
-    // pthread_cleanup_push is intentionally avoided: its struct __ptcb also corrupts
-    // the stack canary on this platform (see "precarious stack guard corruption" above).
-    // HotSpot exits threads via pthread_exit(), not pthread_cancel(), so the destructor
-    // is always reached.
-    struct Cleanup {
-        ~Cleanup() { Profiler::unregisterThread(ProfiledThread::currentTid()); ProfiledThread::release(); }
-    } cleanup;
     routine(params);
-    return nullptr;
+    Profiler::unregisterThread(ProfiledThread::currentTid());
+    ProfiledThread::release();
+    // pthread_exit instead of 'return': the saved LR in this frame is corrupted
+    // by DEOPT PACKING; returning would jump to a garbage address.
+    pthread_exit(nullptr);
 }
 
 static int pthread_create_hook_spec(pthread_t* thread,