mirror of
https://github.com/qpdf/qpdf.git
synced 2025-01-10 18:24:40 +00:00
solved memory leak
git-svn-id: svn+q:///qpdf/trunk@973 71b93d88-0707-0410-a8cf-f5a4172ac649
This commit is contained in:
parent
bf75e208e9
commit
7559934b02
30
TODO
30
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
|
Next
|
||||||
====
|
====
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user