Closed simon-staal closed 6 months ago
Thanks for the report. As for ASAN, I added it to be able to easily catch null pointer derefs, buffer overflows, etc., so having LSAN alongside it was just a freebie, even if it's not perfect.
Maybe try to see if you can reproduce by changing from -O0 to -O2 and testing with ASAN again, although even if this works it just makes debugging a bit more painful so wouldn't recommend.
Just checked, -O2 doesn't do anything in terms of catching the leaks.
TLDR: (relevant for students doing their coursework)
-fsanitize=address -static-libasan
flags don't actually detect the majority of memory leak errors in the current skeleton - remove these and run your program withvalgrind
instead to actually see if you're leaking memory.Full story For context, I've been working on making some improvements to the skeleton compiler we're providing, and I came across some peculiar behaviour when verifying that I'm not leaking any memory.
For starters, the
-fsanitize=address -static-libasan
flags that we're compiling with seem to be quite bad at detecting leaks, as I don't think they provide any instrumentation into the parser and lexer generated files, which is where the majority of memory allocation is done (I confirmed this by intentionally adding memory leaks into the parser, which was completely undetected by the sanitizer). A better way to test is to usevalgrind
(and disable the aforementioned flags as they don't play nice with it), which produces the following output when run on the current version of main:Taking a closer look at what exactly is being leaked (using
--leak-check=full --show-leak-kinds=all
), we can see:Long story short, 3 of these is caused by flex and the other one is caused by not
fclose()
ingyyin
. My PR (pending write access to the repo) will include fixes for both of these - but until then worth being aware of this.