On Valgrind

1
On Valgrind
... if you are so unlucky as to have need of it

• Mike Kordosky
• UCL
• Ely, 2005

2
What is it?

• Valgrind is a tool that finds
• uses of uninitialized memory
• memory leaks (e.g. orphaned pointers)
• cases of illegal memory access
• Runs on any code w/o recompilation... fabulous
• Caveat slow uses lots of memory... run on
  minos?.fnal.gov
• Actually, this is just the Memcheck option.
  Valgrind has some other features too.

3
When to use it?

• Your program seems to leak memory
• Your program crashes in a bizarre way
• inside an obviously safe function/class
• depending on recompilation, time of day, and
  other voodoo
• Your program appears to be non-deterministic

4
How to use it
www-numi.fnal.gov/offline_software/srt_public_cont
ext/WebDocs/valgrind.html



valgrind --toolmemcheck\
--db-attachyes\ --gen-suppressionsyes
\ --suppressionsroot.supp \
--error-limitno \ --leak-checkyes \
(full) loon -bq my_script.C date_file

• Then wait a while...
• if you have db-attach set you need to monitor the
  job

5
Example Output
2536 Invalid write of size 4 2536 at
0x1D350A4F frombuf(char, unsigned)
(Bytes.h319) 2536 by 0x1D3501A6
TBufferoperatorgtgt(int) (TBuffer.h439) 2536
by 0x1D43DFD8 int TStreamerInfoReadBuffer(T
Buffer, char const, int, int, int, int)
(TStreamerInfoReadBuffer.cxx589) 2536 by
0x1E180306 TBranchElementReadLeaves(TBuffer)
(TBranchElement.cxx1829) 2536 by
0x1E171CAA TBranchGetEntry(long long, int)
(TBranch.cxx763) 2536 by 0x1E17DB8A
TBranchElementGetEntry(long long, int)
(TBranchElement.cxx1227) 2536 by
0x1E61A6FD TTreeIndexGetEntry(long long)
(TTreeIndex.cxx182) 2536 by 0x1E619EFA
TTreeIndexTTreeIndex(TTree const, char const,
char const) (TTreeIndex.cxx139) 2536 by
0x1E61BF51 TTreePlayerBuildIndex(TTree const,
char const, char const) (TTreePlayer.cxx312)
2536 by 0x1E1A757E TTreeBuildIndex(char
const, char const) (TTree.cxx1482) 2536
by 0x1CD5EAC2 PerOutputStreamBuildTreeIndex()
(PerOutputStream.cxx656) 2536 by
0x1CD5E7F0 PerOutputStreamWrite()
(PerOutputStream.cxx628) 2536 Address
0x22815B40 is not stack'd, malloc'd or (recently)
free'd 2536

• This is the source of the crash-on-exit problem
  Rustem was having
• TTree apparatus overwriting memory as a result of
  unallocated pointer

6
Example II
21775 LEAK SUMMARY 21775 definitely
lost 146987 bytes in 203 blocks. 21775
indirectly lost 182022 bytes in 968
blocks. 21775 possibly lost 1053631
bytes in 28046 blocks. 21775 still
reachable 35157946 bytes in 93037
blocks. 21775 suppressed 0 bytes in
0 blocks. 21775 Reachable blocks (those to
which a pointer was found) are not
shown. 21775 To see them, rerun with
--show-reachableyes

• Valgrind's summary output
• The program consumed lots of memory but didn't
  actually leak (much)
• Valgrind didn't find the error.... or did it?
• Why?

7
What was it?
CandSliceHandle created
CandSliceHandle dupSliceslice-gtDupHandle()
but never deleted

• Was going on in tracker
• Isn't a real memory leak... just keeping hits
  in memory long after they were necessary
• Found using google-perftools
• but only after identifying tracker as the problem
• Lesson Valgrind useful but not appropriate for
  all leaks... try multiple tools if possible

8
Example google-perftools
AlgTrackSRListRunAlg()
CandSliceHandleDupHandle()
new TObject
leak