title: Can you find memory leaks using gdb (or other tool) from the core file?
body: <p>I am getting a crash due to memory leak (but it's 7 layers deep down, where it merely walks over the linked list - no allocations there).<br>
   It is fairly reproducible, almost on a daily basis, so I can always get a fresh core file. I spent last 3-5 days going over the code, pairing allocation/deallocation but cannot seem to find the place that would cause it, as the legacy C application is huge and it's full of memcpy/alloc/calloc all over the place. Frankly, one wrong memcpy is all it might take.  </p>
  
  <p>I went through the effort of compiling Valgrind locally, looking forward to get some nice tracing where it started, but Valgrind just makes the machine inoperable, e.g. it has to be restarted in the server room manually, as even ssh cannot be used. We basically lost two days of debugging due to Valgrind, so I cannot use it third time (unless Memcheck could somehow work with core files, perhaps?)</p>
  
  <p>Is there some other tool that could help me analyze the core file for memory leaks ? gdb with print command is not exactly helpful.</p>
  
  <p>To be more specific, some core files are really huge - 1.5GB (while they should not be over 0.3GB), so I was hoping to get a list of top 2-3 offenders that occupy most memory (which would give me direct hint as to where look next).</p>
  
  <p>Any ideas ?</p>
  
  <p>Oh, and as for the stability - it can properly handle about a million (or so) of the data requests, before it crashes (sometimes couple millions), so just putting a breakpoint in place where it usually crashes is out of the question.</p>