autofree: os.execute string allocation not freed

[Eliyaan]

Describe the bug

When using os.execute, it allocates a string and that string is not freed by autofree.
Diagnostic by Felipe Pena on discord: https://discord.com/channels/592103645835821068/592294828432424960/1329524135520501852

Reproduction Steps

import os
for _ in 0..100 {
    os.execute("cat bug.v")
}

run with v -autofree -prod -cc gcc -cg -keepc -gc none bug.v and used valgrind --leak-check=full -v ./bug to check for leaks

Expected Behavior

It to be freed (maybe via is_return_used, see the conversation on discord).

Current Behavior

Valgrind:

==27320== HEAP SUMMARY:
==27320==     in use at exit: 61 bytes in 1 blocks
==27320==   total heap usage: 7 allocs, 6 frees, 1,874 bytes allocated
==27320==
==27320== Searching for pointers to 1 not-freed blocks
==27320== Checked 120,768 bytes
==27320==
==27320== 61 bytes in 1 blocks are definitely lost in loss record 1 of 1
==27320==    at 0x4842794: malloc (vg_replace_malloc.c:446)
==27320==    by 0x40927D: malloc_noscan (bug.tmp.c:4578)
==27320==    by 0x41626A: UnknownInlinedFun (bug.tmp.c:4656)
==27320==    by 0x41626A: UnknownInlinedFun (bug.tmp.c:2269)
==27320==    by 0x41626A: os__execute (bug.tmp.c:6544)
==27320==    by 0x4051CF: UnknownInlinedFun (bug.tmp.c:6584)
==27320==    by 0x4051CF: main (bug.tmp.c:6627)
==27320==
==27320== LEAK SUMMARY:
==27320==    definitely lost: 61 bytes in 1 blocks
==27320==    indirectly lost: 0 bytes in 0 blocks
==27320==      possibly lost: 0 bytes in 0 blocks
==27320==    still reachable: 0 bytes in 0 blocks
==27320==         suppressed: 0 bytes in 0 blocks

Possible Solution

No response

Additional Information/Context

No response

V version

V 0.4.9 6ac1d08.f9106a8

Environment details (OS name and version, etc.)

V full version	V 0.4.9 6ac1d08.f9106a8
OS	linux, "Void Linux"
Processor	4 cpus, 64bit, little endian, Intel(R) Pentium(R) Gold 7505 @ 2.00GHz
Memory	16.47GB/23.16GB
V executable	/home/nopana/v/v
V last modified time	2025-01-16 19:06:29
V home dir	OK, value: /home/nopana/v
VMODULES	OK, value: /home/nopana/.vmodules
VTMP	OK, value: /tmp/v_1000
Current working dir	OK, value: /home/nopana/projects/tests
Git version	git version 2.47.1
V git status	weekly.2025.1-67-gf9106a86
.git/config present	true
cc version	cc (GCC) 13.2.0
gcc version	gcc (GCC) 13.2.0
clang version	N/A
tcc version	tcc version 0.9.28rc 2024-07-31 HEAD@1cee0908 (x86_64 Linux)
tcc git status	thirdparty-linux-amd64 0134e9b9
emcc version	N/A
glibc version	ldd (GNU libc) 2.39

Note

You can use the 👍 reaction to increase the issue's priority for developers.

Please note that only the 👍 reaction to the issue itself counts as a vote.
Other reactions and those to comments will not be taken into account.

[huly-for-github]

Connected to Huly®: V_0.6-21920

[kbkpbot]

Yes, I think that V's auto string need some patch to avoid memory leak.
For example ,

leak.v

struct Test {
        a string
}

fn main() {
        cmd := 'ls'
        b := Test {
                a : 'cmd ${cmd} failed'
        }
}

will cause memory leak.

v leak.v -keepc -showcc -gc none -autofree -d trace_autofree && valgrind --error-exitcode=1 --leak-check=full --show-reachable=yes ./leak

==3843350== Memcheck, a memory error detector
==3843350== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==3843350== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==3843350== Command: ./leak
==3843350==
==3843350==
==3843350== HEAP SUMMARY:
==3843350==     in use at exit: 14 bytes in 1 blocks
==3843350==   total heap usage: 3 allocs, 2 frees, 271 bytes allocated
==3843350==
==3843350== 14 bytes in 1 blocks are definitely lost in loss record 1 of 1
==3843350==    at 0x4846828: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==3843350==    by 0x60A327: malloc_noscan (in /home/mars/v/leak/leak)
==3843350==    by 0x60A54F: memdup_noscan (in /home/mars/v/leak/leak)
==3843350==    by 0x601F58: strings__Builder_str (in /home/mars/v/leak/leak)
==3843350==    by 0x60FA28: str_intp (in /home/mars/v/leak/leak)
==3843350==    by 0x610783: main__main (in /home/mars/v/leak/leak)
==3843350==    by 0x610A0F: main (in /home/mars/v/leak/leak)
==3843350==
==3843350== LEAK SUMMARY:
==3843350==    definitely lost: 14 bytes in 1 blocks
==3843350==    indirectly lost: 0 bytes in 0 blocks
==3843350==      possibly lost: 0 bytes in 0 blocks
==3843350==    still reachable: 0 bytes in 0 blocks
==3843350==         suppressed: 0 bytes in 0 blocks
==3843350==
==3843350== For lists of detected and suppressed errors, rerun with: -s
==3843350== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

The generated c code:

VV_LOCAL_SYMBOL void main__main(void) {
        string cmd = _SLIT("ls");
        main__Test b = ((main__Test){.a = str_intp(2, _MOV((StrIntpData[]){{_SLIT("cmd "), 0xfe10, {.d_s = cmd}}, {_SLIT(" failed"), 0, { .d_c = 0 }}})),});
        string_free(&cmd); // autofreed var main false
}

I suggest a new version :

VV_LOCAL_SYMBOL void main__main(void) {
        string cmd = _SLIT("ls");
        string tmp_v0 = str_intp(2, _MOV((StrIntpData[]){{_SLIT("cmd "), 0xfe10, {.d_s = cmd}}, {_SLIT(" failed"), 0, { .d_c = 0 }}}));
        main__Test b = ((main__Test){.a = tmp_v0 ,});
        string_free(&tmp_v0); //  new added
        string_free(&cmd); // autofreed var main false
}