Valgrind 3.9.0

Posted Nov 5, 2013 10:20 UTC (Tue) by Otus (subscriber, #67685)
In reply to: Valgrind 3.9.0 by gutschke
Parent article: Valgrind 3.9.0 released

> 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

Posted Nov 5, 2013 11:08 UTC (Tue) by ballombe (subscriber, #9523) [Link]

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

Valgrind 3.9.0

Posted Nov 5, 2013 14:42 UTC (Tue) by dgm (subscriber, #49227) [Link] (2 responses)

> 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

Posted Nov 5, 2013 16:00 UTC (Tue) by hamjudo (guest, #363) [Link] (1 responses)

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

Posted Nov 5, 2013 16:13 UTC (Tue) by hamjudo (guest, #363) [Link]

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.