$ clang -g -O0 10_return_local.c -o bin/10_return_local
10_return_local.c:79:13: warning: address of stack memory associated
with local variable 'local' returned [-Wreturn-stack-address]
^ Never ignore -Wreturn-stack-address. Build with -Wall and read warnings.$ ./bin/10_return_local ; echo "exit=$?"
*p (first read) = 42
exit=... # varies: the slot is reused after the printf call
^ It "works" once then returns garbage — a textbook flaky dangling-pointer
bug. No crash to anchor on.The plain build doesn't fault, so run the sanitized build under gdb so it STOPS at the bad access and you can inspect frames:
$ clang -g -O0 -fsanitize=address 10_return_local.c -o bin/10_return_local.asan
$ ASAN_OPTIONS=abort_on_error=1 gdb -q -batch \
-ex 'set debuginfod enabled off' -ex run -ex bt ./bin/10_return_local.asan
... ASan halts; bt shows main at 10_return_local.c:84 (the deref) ...$ ./bin/10_return_local.asan
==NNNNN==ERROR: AddressSanitizer: stack-use-after-return on address 0x....
#0 0x... in main .../10_return_local.c:84
Address 0x.... is located in stack of thread T0 at offset 32 in frame
#0 0x... in get_ptr .../10_return_local.c:77
How to read it:
"stack-use-after-return" -> you used a stack slot after its function
returned. ASan names BOTH ends: the USE in main (line 84) and the
FRAME it belonged to — get_ptr (line 77). That second name is the
whole bug. (stack-use-after-return is ON by default in this clang.)$ valgrind -q ./bin/10_return_local
==NNNNN== Use of uninitialised value of size 8
==NNNNN== at 0x...: _itoa_word (...) # deep inside printf
==NNNNN== by 0x...: main (10_return_local.c:84)
META-LESSON: valgrind does NOT say "stack-use-after-return". The dead
stack slot is still MAPPED memory, so memcheck can't call the address
invalid; it only notices, indirectly, that the bytes are uninitialised
once printf consumes them. ASan (with frame red zones) is the right tool
for dangling-stack bugs; valgrind is weak here.ROOT CAUSE vs CRASH SITE: The symptom shows up in main (the deref, line 84) or even deep inside printf — far from the cause. The ROOT CAUSE is `return &local;` (line 79): a pointer escaping its object's lifetime. ASan's "in frame get_ptr" line walks you straight back to the guilty function.
stack error / dangling pointer
3 ------------------------------------------------------------
`get_ptr` returns `&local`, the address of an automatic variable. `local` ceases to exist when `get_ptr` returns, so the caller holds a pointer into a dead stack frame. Buggy line: `return &local;`.
Usually SILENT and FLAKY. The first deref often still reads 42 (the slot hasn't been reused yet); a later deref reads garbage once another call (e.g. printf) reuses that stack. No crash; exit code varies. The COMPILER even warns at build.
Don't return the address of a local. Return by value, or allocate storage that outlives the call (heap, or caller-provided buffer): int get_val(void) { int local = 42; return local; } // by value
Make `local` `static int local = 42;`. The warning and the ASan error both vanish: a static has program lifetime, so &local is valid forever. (Now it's just not reentrant — a different concern.) ============================================================
#include <stdio.h>
__attribute__((noinline)) static int *get_ptr(void) {
int local = 42; /* lives only for this call */
return &local; /* <-- THE BUG: address of a dead local */
}
int main(void) {
int *p = get_ptr(); /* p now dangles into a freed frame */
printf("*p (first read) = %d\n", *p); /* deref dangling pointer */
return *p & 0xff; /* read again: slot may be reused now */
}A lab is done when you can say what it showed on your machine — not when you have read it.
It decides which problems come first, which drills open, which labs you see and how the Learn surface is organised. Change it any time from the switch in the top bar, or press Escape to look around first.