From 7559934b023cd21d17b8f6ea3263282384a9a88f Mon Sep 17 00:00:00 2001 From: Jay Berkenbilt Date: Sat, 5 Jun 2010 21:27:41 +0000 Subject: [PATCH] solved memory leak git-svn-id: svn+q:///qpdf/trunk@973 71b93d88-0707-0410-a8cf-f5a4172ac649 --- TODO | 30 ------------------------------ 1 file changed, 30 deletions(-) diff --git a/TODO b/TODO index 2d7fb1ed..b18c459e 100644 --- a/TODO +++ b/TODO @@ -1,33 +1,3 @@ -Bug -=== - - * Running - - valgrind --leak-check=full .../qpdf --check memory-leak.pdf - - shows a number of QPDFObjects that were not deallocated. They all - seem to be objects allocated by dereference() while in - flattenScalarReferences. - - I'm not sure at this time how it's possible that this memory is - leaked because everything is based on PointerHolder. I've already - ruled out the way the cache is handled...the objects in the cache - overlap with the leaked objects, but they are not exactly the - leaked objects. - - Most files don't exhibit leaks, but all files that have outlines - do. I don't know whether it's because of circular object - references. - - General debugging: put a break point on 'stop_here()' and run qpdf - --check memory-leak.pdf in gdb. For simplicity, configure with - --disabled-shared CFLAGS=-g CXXFLAGS=-g. This will cause gdb to - stop at the point of allocation of all the objects that are leaked. - I'm still not sure which of these is the one that valgrind is - complaining about, and I'm not really even sure that they're - legitimate, though it's hard to imagine that they aren't. - - Next ====