LWN: Comments on "Valgrind 3.9.0 released"

Valgrind 3.9.0

pr1268 — Thu, 07 Nov 2013 22:39:46 +0000

Thank you (and everyone else above) for your replies. Quite enlightening discussion, I might add.

Granted, my C++ "toy" program was merely an academic exercise; I also posted this to stackoverflow a few years ago (my question was more related to how the C++ standard library manages std::string), and the resultant discussion was nearly the same. For the record, I do not write code like that (at least avoiding calling exit(3) in a silly manner), and also I question my own usage of C++ std::string when it's not really needed.

Thanks again, everyone!

Valgrind 3.9.0

rriggs — Thu, 07 Nov 2013 18:10:21 +0000

Thanks for posting this. Too many C++ programmers are unaware of this issue.

"Never exit(3) from a C++ program; either return from main() or abort(3)."

That should be Sutter & Alexandrescu's 102nd rule (or 101st, depending on how you count).

Valgrind 3.9.0

iabervon — Tue, 05 Nov 2013 18:11:55 +0000

This bug is specific to simple objects (strings and arrays) and relates to the fact that the standard library allocates them oddly. If valgrind knew what the standard library were doing, or the code used an object with an interesting destructor, valgrind would give the correct classification, which is "still reachable". Valgrind is correct to warn you, but it's giving the wrong warning, which makes it hard to know what to fix.

Valgrind 3.9.0

hamjudo — Tue, 05 Nov 2013 16:13:54 +0000

Forgot a tip. We renamed main() to realmain(), and wrote a new main() that called the realmain(). realmain() was supposed to free everything it allocated. This gave us a place to put a breakpoint after realmain() returned, but before the system libraries did their cleanup. From the debugger, we could ask Valgrind what was still allocated.

Valgrind 3.9.0

hamjudo — Tue, 05 Nov 2013 16:00:10 +0000

Add a "--slow-exit" option to the program that when used bypasses the normal fast exit path, marks the time, then deallocate everything. If you have issues with consistency of in memory structures, you can add something to walk every structure before deallocation. If you suspect that something is happening in destructor, that shouldn't, use strace to make sure there is no I/O after the mark.

A few jobs ago, we set up cluster of systems to run Valgrind each night on the most recent version of the code. It was amazingly useful. The code was built the same way as what a customer would have gotten, but some parameters were different, so we could run the tests, and verify memory wasn't being lost.

Valgrind 3.9.0

dgm — Tue, 05 Nov 2013 14:42:40 +0000

> Could valgrind somehow find out whether those objects have destructors that could matter?

Short answer: no. It would mean that Valgrind would understand your intent, and/or the intent of every library you happen to be using.

> it would be nice to be able to simply ignore resources you don't care

The problem is you should probably care. Is this last line of output that has yet to be flushed important? That very last commit to the database? The final UDP confirmation packet? Who hasn't seen destructors abused this way a hundred times?

Valgrind 3.9.0

jwakely — Tue, 05 Nov 2013 14:38:10 +0000

N.B. glibc doesn't have an implementation of std::string, glibc is the C library, the implementation you're referring to belongs to libstdc++, which is part of GCC.

Valgrind 3.9.0

mathstuf — Tue, 05 Nov 2013 13:30:36 +0000

It uses pointer magic to avoid a second allocation for the actual data. The comment in the string header is useful.

Valgrind 3.9.0

ballombe — Tue, 05 Nov 2013 11:08:40 +0000

valgrind is not a C++ interpretor, but a binary interpretor where there is no notion of destructor.

Valgrind 3.9.0

Otus — Tue, 05 Nov 2013 10:20:22 +0000

> Yes, in practice, you are probably fine with basic objects such as the one that you show here. But for more complex objects, it does make a real difference whether destructors are run before the program terminates. And it is a good thing if valgrind warns about it.

Could valgrind somehow find out whether those objects have destructors that could matter? Because it would be nice to be able to simply ignore resources you don't care about at program exit but still have valgrind warn about things that are potentially dangerous (e.g. a destructor that's supposed to clean up a lock file).

I hate programs that spend a lot of time closing down stuff after I've told them to exit, and deallocating *memory* on shut down is completely useless.

Valgrind 3.9.0

edeloget — Tue, 05 Nov 2013 09:23:36 +0000

Well, the C++ standard explicitely says that calling exit(3) prevents the execution of automatic variables destructors - so of course you leak the memory. See section 3.6.1 [basic.start.main] §4.

bugfix 280271 fixes another problem related to the fact that the glibc implementation of std::string internal pointer does not point to the beginning of the allocated block. It uses weird (*) magic to suppress some false-positive.

(*) as in: tied to a particular implementation ; an implementation change in either the C++ standard library or in the compiler's new[] implementation will defeat this magic.

Valgrind 3.9.0

gutschke — Tue, 05 Nov 2013 03:13:37 +0000

I would argue that valgrind's warning message is correct, if maybe annoying.

Valgrind verifies that you have released all (memory) resources prior to terminating the program. If you fall off the end of main(), then C++ will implicitly deallocate resources when "s" goes out of scope. But your code never gives this mechanism any chance to run.

Yes, in practice, you are probably fine with basic objects such as the one that you show here. But for more complex objects, it does make a real difference whether destructors are run before the program terminates. And it is a good thing if valgrind warns about it.

For production code, you could argue that there are some objects that you never want to destruct for one reason or another. And that's certainly a valid argument to make. But valgrind gives you plenty of tools to suppress warnings, if you have explicitly checked that the default behavior is inappropriate for some objects.

So, I'd claim that valgrind is working as in intended for your example.

Valgrind 3.9.0

samlh — Tue, 05 Nov 2013 03:06:00 +0000

> I'm wondering if bugfix 280271 fixes that?

Yes.

Use --leak-check-heuristics=stdstring (or all) to get a result like:

still reachable: 56 bytes in 2 blocks of which reachable via heuristic:
stdstring : 56 bytes in 2 blocks

Valgrind 3.9.0

pr1268 — Tue, 05 Nov 2013 01:48:13 +0000

280271 Valgrind reports possible memory leaks on still-reachable std::string

I always like to "bluff" valgrind with this C++ program:

#include <cstdlib> // for exit(3)
#include <string>
#include <iostream>

void die()
{
    exit(0);
}

int main()
{
    std::string s("Hello, World!");
    std::cout << s << std::endl;
    die();
    return 0;
}

With the "dangling" std::string, valgrind seems to think 26 bytes are "possibly lost". I'm wondering if bugfix 280271 fixes that? (Or if I really should care?) ;-)

P.S. My sincere thanks to the valgrind development team for another release.

Valgrind @ Fosdem 2014

mjw — Mon, 04 Nov 2013 22:32:18 +0000

Valgrind will also have a developer room at Fosdem. See the Call For Participation: https://lists.fosdem.org/pipermail/fosdem/2013-October/00...