Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Twenty years of Valgrind

nnethercote.github.io

Post reply on HN
Print view View original

81–90 of 118 posts

Re: Twenty years of Valgrind

#81

Post by pjmlp »

oconnor663 wrote: post #75
pjmlp wrote: post #61

> Speaking of software quality, I think it’s fitting that I now work full time on Rust, a systems programming language that didn’t exist when Valgrind was created, but which basically prevents all the problems that Memcheck detects. Just like Ada has been doing since 1983.

My understanding is that dynamically freeing memory is an unsafe operation in Ada, do I have that right?

Depends on which dynamic memory you are talking about.

Ada can manage dynamic stacks, strings and arrays on its own.

For example, Ada has what one could call type safe VLAs, instead of corrupting the stack like C, you get an exception and can redo the call with a smaller size, for example.

As for explicit heap types and Ada.Unchecked_Deallocation, yes if we are speaking about Ada 83.

Ada 95 introduced controlled types, which via Initialize, Adjust, and Finalize, provide the basis of RAII like features in Ada.

Here is an example on how to implement smart pointers with controlled types,

https://www.adacore.com/gems/gem-97-reference-counting-in-ad...

There is also the possiblity to wrap heap allocation primitives with safe interfaces exposed via storage pools, like on this tutorial https://blog.adacore.com/header-storage-pools

Finally thanks to SPARK, nowadays integrated into Ada 2012[0], you can also have formal proofs that it is safe to release heap memory.

In top of all this, Ada is in the process of integrating affine types as well.

[0] - Supported in PTC and GNAT, remaining Ada compilers have a mix of Ada 95 - 2012 features, see https://news.ycombinator.com/item?id=27603292

Re: Twenty years of Valgrind

#82

Post by tarasglek »

Beyond raw technical ability, Nick and Julian were the kindest, most reasonable developers I've ever interacted with. I think a lot of Valgrind's success stems from combination of sophisticated tech and approachability of the core team.

Re: Twenty years of Valgrind

#83

Post by gpderetta »

Sesse__ wrote: post #79
glouwbug wrote: post #10

Earlier quoted context omitted.

Yeah, valgrind can report L1/L2 cache misses and report the percentage of branch mispredictions. It also reports the exact number of instructions processed, and how many of those instructions cache missed. It's great for improving small code that needs to be performant. I'd use asan over valgrind only for memory leaks. It's faster.

If you only want memory leaks, LSan will do that for you. In general, I tend to use ASan for nearly everything I used Valgrind for back in the day; it's faster and usually more precise (Valgrind cannot reliably detect small overflows between stack variables). Valgrind if I cannot recompile, or if ASan doesn't find th issue. Callgrind and Cachegrind never; perf does a much better job, much faster. DHAT never; Heaptrac…

Amen. Between the various sanitizers and perf, I stopped needing valgrind a few years ago.

But when it was the only option it was fantastically useful.

Re: Twenty years of Valgrind

#84

Post by pbhjpbhj »

wenc wrote: post #73
Olumde wrote: post #31

Happy birthday Valgrind. Next year you'll be able to drink in the US! Being a UK PhD holder, a sentence stood out out to me was a commentary/comparison between UK and US PhDs: "This was a three year UK PhD, rather than a brutal six-or-more year US PhD." My cousin has a US PhD and judging from what he tells me. It is a lot more rigorous than UK PhDs.

The UK PhD is 3 yrs, after a 1 yr Masters and 3 yr bachelors. (7 years) The US PhD is usually 4-5 years after a 4 year bachelors (8-9 years). It is a little bit longer with more graduate-level coursework. That said, the US bachelors starts at age 17 while a UK bachelors starts after 2 years of A-levels. So in terms of length it’s a wash.

FWIW, you have to be slightly careful as Scotland has a different post-16 education provision.

AIUI you can do Highers (equivalent to GCSE, at 16) and enter Uni then with sufficiently high grades (aged 16/17). Or, stay on for one more year to do Advanced Higher (most common). Uni courses can then be 4 or occasionally 3 years. Don't quote me!

Re: Twenty years of Valgrind

#85

Post by j1elo »

Valgrind is an amazingly useful tool. The biggest pain point, though, has always been to read through and process the huge amount of false positives that typically come from 3rd-party support libraries, such as GLib. It provides some suppression files to be used with Valgrind, but still, GLib has its own memory allocator, so things tend to go awry.

Running Helgrind or DRD (for threading issues) with GLib has been a bit frustrating, too. If anyone has some advice to share about this, I'm all ears!

(EDIT: I had mistakenly left out the phrase about suppression files)

Re: Twenty years of Valgrind

#86

Post by intelVISA »

imetatroll wrote: post #71
dijonman2 wrote: post #47

Earlier quoted context omitted.

I’m surprised to see the attribution to the tools and not your proposed fixes. Sure the discovery was the first step in the order of operations, but can you elaborate on what enabled you to understand the problem statement and subsequent resolution? There has to be a deeper understanding I think

Sounds like the solution probably had something to do with switching to passing by reference + other changes I would assume.

A big pain point for using coroutines is having to pass-by-value more frequently due to uncertain lifetimes.. it's jarring when you come from zero copy programming.

Re: Twenty years of Valgrind

#87

Post by intelVISA »

compiler-guy wrote: post #22

I sort of owe callgrind a big chunk of my career. I was working at a company full of PhDs and well seasoned veterans, who looked at me as a new kid, kind of underqualified to be working in their tools group. I had been at the firm for a while, and they were nice enough, but didn't really have me down as someone who was going to contribute as anything other than a very junior engineer. We had a severe problem with a p…

Always find it weird when people berate C++ tooling, Valgrind and adjacent friends are legitimately best in class and incredibly useful. Between RAII and a stack of robust static analyzers you'd have to deliberately write unsafe code these days.

Re: Twenty years of Valgrind

#88

Post by themulticaster »

glouwbug wrote: post #10
galangalalgol wrote: post #7

Earlier quoted context omitted.

Our pipelines have asan ( and cpp check clang tidy coverity and coverage stuff) but no valgrind, is there something it is good at that we are missing?

Yeah, valgrind can report L1/L2 cache misses and report the percentage of branch mispredictions. It also reports the exact number of instructions processed, and how many of those instructions cache missed. It's great for improving small code that needs to be performant. I'd use asan over valgrind only for memory leaks. It's faster.

If I understand correctly valgrind (cachegrind) reports L1/L2 cache misses based on a simulated CPU/cache model.

On Linux, you can easily instrument real cache events using the very powerful perf suite. There is an overwhelming number of events you can instrument (use perf-list(1) to show them), but a simple example could look like this:

  $ perf stat -d -- sh -c 'find ~ -type f -print | wc -l'
  ^Csh: Interrupt
   Performance counter stats for 'sh -c find ~ -type f -print | wc -l':
  
               47,91 msec task-clock                #    0,020 CPUs utilized
                 599      context-switches          #   12,502 K/sec
                  81      cpu-migrations            #    1,691 K/sec
                 569      page-faults               #   11,876 K/sec
         185.814.947      cycles                    #    3,878 GHz                      (28,71%)
         105.650.405      instructions              #    0,57  insn per cycle           (46,15%)
          22.991.322      branches                  #  479,863 M/sec                    (46,72%)
             643.767      branch-misses             #    2,80% of all branches          (46,14%)
          26.010.223      L1-dcache-loads           #  542,871 M/sec                    (36,80%)
           2.449.173      L1-dcache-load-misses     #    9,42% of all L1-dcache accesses  (29,62%)
             517.052      LLC-loads                 #   10,792 M/sec                    (22,53%)
             133.152      LLC-load-misses           #   25,75% of all LL-cache accesses  (16,02%)
  
         2,403975646 seconds time elapsed
  
         0,005972000 seconds user
         0,046268000 seconds sys
Ignore the command, it's just a placeholder to get meaningful values. The -d flag adds basic cache events, by adding another -d you also get load and load miss events for the dTLB, iTLB and L1i cache.

But as mentioned, you can instrument any event supported by your system. Including very obscure events such as uops_executed.cycles_ge_2_uops_exec (Cycles where at least 2 uops were executed per-thread) or frontend_retired.latency_ge_2_bubbles_ge_2 (Retired instructions that are fetched after an interval where the front-end had at least 2 bubble-slots for a period of 2 cycles which was not interrupted by a back-end stall).

You can also record data using perf-record(1) and inspect them using perf-report(1) or - my personal favorite - the Hotspot tool (https://github.com/KDAB/hotspot).

Sorry for hijacking the discussion a little, but I think perf is an awesome little tool and not as widely known as it should be. IMO, when using it as a profiler (perf-record), it is vastly superior to any language-specific built-in profiler. Unfortunately some languages (such as Python or Haskell) are not a good fit for profiling using perf instrumentation as their stack frame model does not quite map to the C model.

Re: Twenty years of Valgrind

#89

Post by nicoburns »

intelVISA wrote: post #87
compiler-guy wrote: post #22

I sort of owe callgrind a big chunk of my career. I was working at a company full of PhDs and well seasoned veterans, who looked at me as a new kid, kind of underqualified to be working in their tools group. I had been at the firm for a while, and they were nice enough, but didn't really have me down as someone who was going to contribute as anything other than a very junior engineer. We had a severe problem with a p…

Always find it weird when people berate C++ tooling, Valgrind and adjacent friends are legitimately best in class and incredibly useful. Between RAII and a stack of robust static analyzers you'd have to deliberately write unsafe code these days.

That sounds great until you realise in other languages you get that by default without any tooling. And with better guarantees too (C++ static analysers aren’t foolproof).

Where C++ tooling really lacks is around library management and build tooling. The problem is less that any of the individual tools don’t work and more that there are many of them and they don’t interoperate nicely.

Re: Twenty years of Valgrind

#90

Post by rwmj »

anewpersonality wrote: post #59

Is Valgrind any use in Rust?

Not used it with Rust, but have used it with OCaml, Perl, Ruby, Tcl successfully. In managed languages it's mainly useful for detecting problems in C bindings rather than the language itself. Languages where it doesn't work well: Python and Golang.
Post reply on HN