Why won’t valgrind detect a memory leak in a basic program with a leak?

Question

My Code:

#include <stdlib.h>
#include <stdio.h>

int main() {
        char* string = malloc(50 * sizeof(char));
        printf("my code ran\n");
        return 0;

}

I compiled it with:

gcc -o mem memErr.c

and ran it with

valgrind ./mem

and

valgrind --leak-check=yes ./mem

but my output was

(cmd)(base) ~/Documents/c/summerC$ valgrind --leak-check=yes ./mem
==65172== Memcheck, a memory error detector
==65172== Copyright (C) 2002-2017, and GNU GPL`d, by Julian Seward et al.
==65172== Using Valgrind-3.17.0.GIT-lbmacos and LibVEX; rerun with -h for copyright info
==65172== Command: ./mem
==65172==
==65172== Warning: set address range perms: large range [0x7fff202d0000, 0x8000200d0000) (defined)
==65172== Warning: set address range perms: large range [0x7fff202d0000, 0x7fff7ff88000) (defined)
==65172== Warning: set address range perms: large range [0x7fff8e23c000, 0x7fffc02d0000) (noaccess)
==65172== Warning: set address range perms: large range [0x7fffc02d0000, 0x7fffe2560000) (defined)
==65172== Warning: set address range perms: large range [0x7fffe2560000, 0x7fffffe00000) (noaccess)
my code ran
==65172==
==65172== HEAP SUMMARY:
==65172==     in use at exit: 0 bytes in 0 blocks
==65172==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==65172==
==65172== All heap blocks were freed -- no leaks are possible
==65172==
==65172== For lists of detected and suppressed errors, rerun with: -s
==65172== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Why dosn't valgrind report a memory leak here?

Edit: Based on comments from @dbush and @AJIOB I tried changing the code to:

#include <stdlib.h>
#include <stdio.h>
#include <string.h>
int main() {
    char* string = malloc(50 * sizeof(char));
    strcpy(string, "my new code ran");
    printf("%s\n", string);
    return 0; 
}

and compiling with: gcc -g -o mem memErr.c but the result is the same:

(cmd)(base) ~/Documents/c/summerC$ valgrind ./mem
==81073== Memcheck, a memory error detector
==81073== Copyright (C) 2002-2017, and GNU GPL`d, by Julian Seward et al.
==81073== Using Valgrind-3.17.0.GIT-lbmacos and LibVEX; rerun with -h for copyright info
==81073== Command: ./mem
==81073==
==81073== Warning: set address range perms: large range [0x7fff202d0000, 0x8000200d0000) (defined)
==81073== Warning: set address range perms: large range [0x7fff202d0000, 0x7fff7ff88000) (defined)
==81073== Warning: set address range perms: large range [0x7fff8e23c000, 0x7fffc02d0000) (noaccess)
==81073== Warning: set address range perms: large range [0x7fffc02d0000, 0x7fffe2560000) (defined)
==81073== Warning: set address range perms: large range [0x7fffe2560000, 0x7fffffe00000) (noaccess)
my new code ran
==81073==
==81073== HEAP SUMMARY:
==81073==     in use at exit: 0 bytes in 0 blocks
==81073==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==81073==
==81073== All heap blocks were freed -- no leaks are possible
==81073==
==81073== For lists of detected and suppressed errors, rerun with: -s
==81073== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

Edit: The issue seems to be a macOS Big Sur compatibility issue with valgrind. My current workaround is using a virtual linux environment with Docker to run valgrind.

Answer 1

Since the memory returned from malloc was never used, the compiler probably optimized the call away.

This line in the valgrind output seems to back that up:

total heap usage: 0 allocs, 0 frees, 0 bytes allocated

If you modify the code so that the malloc'ed buffer is used, valgrind should report a leak:

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

int main() {
        char* string = malloc(50 * sizeof(char));
        strcpy(string, "my code ran");
        printf("%s\n", string);
        return 0;

}

Answer 2

From Valgrind Quick start guide : you should compile your program with -g flag (debug symbols).

Also, as @dbush user said, you should operate with your string for telling the compiler, that your variable is really required.