[HN Gopher] Valgrind recieves a development microgrant from FUTO
___________________________________________________________________
Valgrind recieves a development microgrant from FUTO
Author : pabs3
Score : 79 points
Date : 2023-07-23 12:22 UTC (10 hours ago)
(HTM) web link (fosstodon.org)
(TXT) w3m dump (fosstodon.org)
| kichik wrote:
| Maybe they can finally merge my 10 year old patch /s
|
| https://bugs.kde.org/show_bug.cgi?id=290061
| spacemanspiff01 wrote:
| What is the use case for valgrind vs memory sanitizer?
| rwmj wrote:
| Valgrind is super-practical because you can use it on any
| existing binary. Basically every project I'm involved in has a
| "make check-valgrind" rule which runs all the unit tests again,
| but under valgrind. It has caught countless memory leaks
| (mainly) and memory errors. We also run it on Rust, OCaml and
| Perl code.
| er4hn wrote:
| What does it catch under Rust? Unsafe code? I'm under the
| impression the borrow checker would prevent the class of
| problems valgrind is made for.
| dralley wrote:
| It could probably catch some leaks. Rust doesn't make you
| immune to leaked memory.
| rwmj wrote:
| I don't recall valgrind catching anything in Rust code
| right now, but do remember that we're binding to C
| libraries so it's still possible for them to leak; or as
| you say something inside an unsafe clause.
| pengaru wrote:
| valgrind does far more than asan-like analysis.
| --tool=callgrind for instance
| mtklein wrote:
| Valgrind is like all the sanitizers (memory, thread, leak,
| address, undefined) all together, plus performance and memory
| profilers, all for uninstrumented code.
|
| For me the real key is the last part. If you're happy building
| and testing with sanitizers from source, I don't think there's
| much more to gain by adding Valgrind to the mix, but if
| sanitizers aren't available or you find yourself with a binary
| and not source, I'd check out Valgrind.
| nlewycky wrote:
| > Valgrind is like all the sanitizers (memory, thread, leak,
| address, undefined) all together, plus performance and memory
| profilers, all for uninstrumented code.
|
| Valgrind as memcheck can do memory and leak and partially do
| address sanitizer, and when run as helgrind can do thread
| sanitizer _. Valgrind doesn 't do -fsanitize=undefined.
|
| Undefined -- UBSan -- in particular doesn't overlap with
| valgrind. Your CPU uses the same instructions for signed and
| unsigned integer addition (thanks to 2's complement) but
| UBSan will catch signed integer overflow. UBSan will catch
| misaligned pointers whether the CPU permits unaligned
| accesses or not. UBSan will catch integer and float divide by
| zero, which valgrind ignores because at the CPU level those
| have defined behaviours (of setting an error flag or
| whatnot).
|
| As for partially doing address sanitizer, ASan improves its
| probability of catching invalid pointer arithmetic by
| intentionally spacing out stack allocations and global
| variables in a way that the compiler is allowed to do but
| which valgrind can't because valgrind has to emulate the CPU
| instructions as they lie. ASan also replaces malloc with its
| own version that attempts to give different addresses as much
| as possible so that the use of a freed pointer is maximally
| likely to not accidentally point to memory which has since
| been reallocated.
|
| Optionally ASan also includes special features like "after
| running the inliner, malloc a fresh stack for every function
| call" so that you can really catch stack use after return htt
| ps://github.com/google/sanitizers/wiki/AddressSanitizerUs...
|
| _ I'm not deeply familiar with either ThreadSanitizer or
| Helgrind. The TSan devs claim that Helgrind either runs in
| "catches too few bugs" mode or "has too many false positives"
| mode and that they got it just right in TSan. I can't
| evaluate that claim. https://static.googleusercontent.com/med
| ia/research.google.c...
| JonChesterfield wrote:
| Valgrind works on arbitrary code. Even if it's doing things
| like jit compilation or self modifying code. Without requiring
| the compiler to have injected instrumentation ahead of time.
|
| There's a lot of C I've written which is only correct because I
| ran the test suite under valgrind while implementing it.
| ahartmetz wrote:
| It can detect more errors and you don't need to recompile
| anything.
| hannob wrote:
| Generally asan+msan detect more errors, and some quite
| significant ones. For design reasons, valgrind cannot detect
| most stack oob bugs. The only issue with msan is that it's a
| bit trickier to use, particularly if you have lots of
| dependencies.
|
| Both approaches have their right to exist, but I have been
| preaching to people that valgrind does not find all memory
| safety bugs that modern tools can find, and they should be
| testing with sanitizers. I still experience that many people
| are not aware of asan+co and only know valgrind.
| dezgeg wrote:
| How well does ASAN cope when the libraries your application
| uses aren't compiled with ASAN? Does it cause false
| negatives or false positives?
| not_your_vase wrote:
| So what's a microgrant? On futo.org I can find only some links
| for legendary grants, which I guess isn't micro.
| CoBE10 wrote:
| As far as I understand it, microgrants are given out every
| month by people within FUTO, as a thank-you to software... that
| is used by people withing the organization. From the video they
| did in May, I think those grants are about $1000.
___________________________________________________________________
(page generated 2023-07-23 23:03 UTC)