2
1
mirror of https://github.com/qpdf/qpdf.git synced 2024-12-23 03:18:59 +00:00

solved memory leak

git-svn-id: svn+q:///qpdf/trunk@973 71b93d88-0707-0410-a8cf-f5a4172ac649
This commit is contained in:
Jay Berkenbilt 2010-06-05 21:27:41 +00:00
parent bf75e208e9
commit 7559934b02

30
TODO
View File

@ -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
====