Arch Linux

acottrell

Member

Registered: 2013-12-17

Posts: 37

valgrind execution time

It seems that some Arch update within the last few months (sorry, a bit vague) has made valgrind a lot slower on my machines. Now, on most invocations, valgrind (or a dependency thereof) spends several seconds hitting eth0 before the program gets down to business. I guess this has to do with debuginfod going out to look for debugging info (I now have 78MB of stuff in ~/.cache/debuginfod/).

I'm not going to complain about the software ensuring it has up-to-date debugging info, that's obviously good. But I do have two questions.

1) Is this really something relatively new? (I certainly don't remember seeing valgrind thrash eth0 earlier this year.)

2) Is there a settable expiry time for debugging info? It seems that the relatively lengthy network access occurs pretty much every time I call valgrind, even if the calls are only a few minutes apart and pertain to the same program under test.

I'm wondering if there's a setting, or maybe some sort of glue between valgrind and debuginfod, that could be missing or broken on my system.

Last point: there's no problem with the correctness of valgrind, apparently it's finding whatever it needs. My only issue is how long it's taking (and this is on a generally fast University network).

acottrell

Member

Registered: 2013-12-17

Posts: 37

Re: valgrind execution time

There's a closely related discussion at https://bugzilla.redhat.com/show_bug.cgi?id=2051971

The environment variables $DEBUGINFOD_URLS and $DEBUGINFOD_TIMEOUT are relevant. Running valgrind with the -v flag shows more of what's happening. I'm guessing that Arch's automatic activation of debuginfod is indeed something relatively new (August 1 of this year?).

PBS

Member

Registered: 2015-06-28

Posts: 53

Re: valgrind execution time

The current valgrind behaviour is a serious regression. Launching a large application takes ~10 minutes to start up even with a fast 35MB/s internet connection. This doesn't just happen first time, but every time.

From man debuginfod, ideally you could disable this with

DEBUGINFOD_URLS= valgrind program-name

but unfortunately, due to https://bugs.archlinux.org/task/74755 (closed wontfix), this breaks valgrind completely.

Currently the best hope of a workaround seems to be either of

DEBUGINFOD_TIMEOUT=1 valgrind program-name
DEBUGINFOD_MAXTIME=1 valgrind program-name

although this still isn't ideal, because it still results in valgrind pinging servers, when all I really want is valgrind to use whatever cached debuginfo it can find locally and ignore anything else - I don't want my debugging tools to be pinging servers when I haven't asked them to!

The only workaround I've found for that is to temporarily disable networking while running valgrind... which is something I'd expect to have to do on Android, not Arch Linux.

Allan

Pacman

From: Brisbane, AU

Registered: 2007-06-09

Posts: 11,537

Website

Re: valgrind execution time

The bug you linked is not directly asking about the same issue.  File a bug if you expect to be able to use valgrind without network access.

---

PGP Key: F99FFE0FEAE999BD | I develop pacman - buy me a drink!

rekaerst

Member

Registered: 2021-06-04

Posts: 1

Re: valgrind execution time

Disable debuginfod with:

DEBUGINFOD_URLS=: valgrind <program>

This won't break valgrind.
Actually, valgrind won't use debuginfod as long as DEBUGINFOD_URLS contains an invalid  url.