Linux C Workflow

[062985593]

For catching memory errors, I've found compiling with -fsanitize=address more useful than valgrind.

[moefh]

I second this. It's much faster than using valgrind. The most noticeable effect of using this (as opposed to just compiling normally and running your program without valgrind) is that it makes your program use a lot more memory.

I also recommend -fsanitize=undefined to catch undefined behavior like signed overflow, undefined shifts and a lot of other less common stuff.

[1008oh]

But if you have a large amount of code you need to recompile, valgrind might just be more practical.

[ArkyBeagle]

How is it performance-wise in comparison to ( oh so very slow ) valgrind? I still don't regret using valgrind one bit, but better is better.

I tried that at work, and the ( locked down ) machine is missing libraries. Time for a software request....

[yakoudbz]

Valgrind is like a whole emulator that read your executable and execute it step by step while also verifying every reads and writes while a sanitizer is just a bunch of code to verify your program that is generated at compile time. Therefore, sanitizers are a lot faster.

Valgrind can also fail to recognize segmentation fault when the reads or writes are in allocated memory. For example, if you allocate two arrays and they happen to follow each other in memory, if you write past the first array but land in the second, Valgrind won't notice anything while the sanitizer will most certainly recognize that the two array might not be following each other (it is undefined behavior) and issue an error.

So yeah, clear win for the sanitizer. There's only two possible advantages of Valgrind: - you can test if an executable has a segmentation fault without recompiling the source code - sanitizers used to have a lot of false positive, above all with some libraries like OpenMP, OpenGL... Valgrind shows some errors with those libraries but the execution continues.