Memory leak goes away?

[Gat Pelsinger]

This code in C will create a massive memory leak.

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

int main(){
    srand(time(NULL));
    for (unsigned long long i = 0; i <= ULONG_LONG_MAX; i++){
        long long *a = (long long *)malloc(sizeof(long long));
        *a = rand();
        //printf("%p\n", *a);
    }
}

But if I uncomment the printf function, there is no memory leak. Why is that?

[trag1c]

This will ultimately depend on your compiler. A compiler may choose to optimize much of your code away since you're only assigning to 'a' and not accessing, essentially see's it as a superfluous call that has no net effect on the outcome.

 

GCC from -O0 to -O3 for optimization will keep the malloc call but using the same flags on clang show a much different story where the malloc disappears. See the assembly below and you can see. This with printf() commented out.

 

GCC 13 with -O3

main:
        push    {r4, lr}
        movs    r0, #0
        bl      time
        bl      srand
.L2:
        movs    r0, #8
        bl      malloc # YOUR MALLOC CALL
        mov     r4, r0
        bl      rand
        str     r0, [r4]
        asrs    r0, r0, #31
        str     r0, [r4, #4]
        b       .L2

 

Clang with 17 with -O3 with no Malloc

main:                                   # @main
        push    rax
        xor     edi, edi
        call    time@PLT
        mov     edi, eax
        call    srand@PLT
.LBB0_1:                                # =>This Inner Loop Header: Depth=1
        call    rand@PLT
        jmp     .LBB0_1

 

Even with the printf() call uncommented Clang still does not generate the call to malloc while GCC does. If optimization is turned off Clang will happily generate the malloc call as you would expect.

 

main:                                   # @main
        push    rbp
        mov     rbp, rsp
        sub     rsp, 32
        mov     dword ptr [rbp - 4], 0
        xor     eax, eax
        mov     edi, eax
        call    time@PLT
        mov     edi, eax
        call    srand@PLT
        mov     qword ptr [rbp - 16], 0
.LBB0_1:                                # =>This Inner Loop Header: Depth=1
        cmp     qword ptr [rbp - 16], -1
        ja      .LBB0_4
        mov     edi, 8
        call    malloc@PLT
        mov     qword ptr [rbp - 24], rax
        call    rand@PLT
        movsxd  rcx, eax
        mov     rax, qword ptr [rbp - 24]
        mov     qword ptr [rax], rcx
        mov     rax, qword ptr [rbp - 24]
        mov     rsi, qword ptr [rax]
        lea     rdi, [rip + .L.str]
        mov     al, 0
        call    printf@PLT
        mov     rax, qword ptr [rbp - 16]
        add     rax, 1
        mov     qword ptr [rbp - 16], rax
        jmp     .LBB0_1
.LBB0_4:
        mov     eax, dword ptr [rbp - 4]
        add     rsp, 32
        pop     rbp
        ret
.L.str:
        .asciz  "%p\n"

 

 

[Gat Pelsinger]

@trag1c I am only using GCC from Mingw-w64. If the compiler does no optimization when there is no printf function, why does it suddenly do some optimization when printf is called? Does the printf function itself has some kind of optimization handling or a call to the compiler for optimization?

[wanderingfool2]

1 hour ago, Gat Pelsinger said:

@trag1c I am only using GCC from Mingw-w64. If the compiler does no optimization when there is no printf function, why does it suddenly do some optimization when printf is called? Does the printf function itself has some kind of optimization handling or a call to the compiler for optimization?

So I guess the question becomes, what makes you think that it's going away?

 

Are you assuming it's going away because your program isn't "crashing" immediately?  I'm assuming you must be getting like assigning to an invalid memory address; as when malloc cannot get more memory it returns a 0 and you assign without checking for 0.

 

Anyways, printf is a relatively slow function; so if you are assuming memory leak goes away because it's not really crashing it might just be that it's just taking a lot longer since it has to print all the stuff first.

[Gat Pelsinger]

@wanderingfool2 I can see in task manager. Without the printf, my memory usage keeps increasing to the point of system hang. Windows fights for memory rights for minutes and then returns back terminating the program. After inserting the printf function, my memory usage is locked at 0.5 MB. It never goes up.

[wasab]

Try running valgrind to run a scan of your heap memory. C has many strange quirks especially when it comes to memory management. You can tell why many developers jump to rust. 

[Franck]

On 12/5/2023 at 10:02 PM, wasab said:

Try running valgrind to run a scan of your heap memory. C has many strange quirks especially when it comes to memory management. You can tell why many developers jump to rust. 

lol

[wasab]

On 12/7/2023 at 4:17 AM, Franck said:

lol

you just wait and see. no one can stop the future.