diff options
author | Jay Berkenbilt <ejb@ql.org> | 2010-05-31 19:12:22 +0200 |
---|---|---|
committer | Jay Berkenbilt <ejb@ql.org> | 2010-05-31 19:12:22 +0200 |
commit | 70f9dc9acf47b2ffb98c89fce17dd939c84cd27d (patch) | |
tree | e63fc29237d6aeabbba0e961d406f14799cb2ec4 | |
parent | aa093bfabd140ee7e526577913fba8cc03ad4bac (diff) | |
download | qpdf-70f9dc9acf47b2ffb98c89fce17dd939c84cd27d.tar.zst |
current notes
git-svn-id: svn+q:///qpdf/trunk@969 71b93d88-0707-0410-a8cf-f5a4172ac649
-rw-r--r-- | TODO | 35 |
1 files changed, 35 insertions, 0 deletions
@@ -1,3 +1,38 @@ +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 +==== + + * Work in contrib/vc6. See email from stronghorse@tom.com + 2.2 === |