Summary
Running shecc under Valgrind reports reproducible definite leaks in the compiler driver, even for a minimal input program.
This appears to come from:
- heap-allocated
token_stream_t objects in gen_file_token_stream() / gen_libc_token_stream()
- heap-allocated predefined
macro_t objects in preprocess()
- cached source buffers stored in
SRC_FILE_MAP whose values are not released before freeing the hashmap
Reproduction
Minimal input:
int main(void)
{
return 0;
}
Command:
cat > /tmp/shecc-minimal.c <<'EOF'
int main(void)
{
return 0;
}
EOF
valgrind \
--tool=memcheck \
--leak-check=full \
--show-leak-kinds=all \
--track-origins=yes \
./out/shecc --no-libc -o /tmp/minimal.elf /tmp/shecc-minimal.c
The same issue is also reproducible without --no-libc, but --no-libc shows that the leak is not caused by <stdio.h> or other libc usage.
Observed result
Valgrind reports:
definitely lost: 512 bytes in 6 blocks
indirectly lost: 34 bytes in 1 blocks
Expected result
definitely lost and indirectly lost should both be 0 for this minimal run.
Summary
Running
sheccunder Valgrind reports reproducible definite leaks in the compiler driver, even for a minimal input program.This appears to come from:
token_stream_tobjects ingen_file_token_stream()/gen_libc_token_stream()macro_tobjects inpreprocess()SRC_FILE_MAPwhose values are not released before freeing the hashmapReproduction
Minimal input:
Command:
The same issue is also reproducible without
--no-libc, but--no-libcshows that the leak is not caused by<stdio.h>or other libc usage.Observed result
Valgrind reports:
definitely lost: 512 bytes in 6 blocksindirectly lost: 34 bytes in 1 blocksExpected result
definitely lostandindirectly lostshould both be 0 for this minimal run.