OpenSystemsDevelopment / qpdf

Authored by Jay Berkenbilt 2010-05-31 17:12:22 +0000


git-svn-id: svn+q:///qpdf/trunk@969 71b93d88-0707-0410-a8cf-f5a4172ac649

Showing 1 changed file with 35 additions and 0 deletions

TODO

	1	+Bug
	2	+===
	3	+
	4	+ * Running
	5	+
	6	+ valgrind --leak-check=full .../qpdf --check memory-leak.pdf
	7	+
	8	+ shows a number of QPDFObjects that were not deallocated. They all
	9	+ seem to be objects allocated by dereference() while in
	10	+ flattenScalarReferences.
	11	+
	12	+ I'm not sure at this time how it's possible that this memory is
	13	+ leaked because everything is based on PointerHolder. I've already
	14	+ ruled out the way the cache is handled...the objects in the cache
	15	+ overlap with the leaked objects, but they are not exactly the
	16	+ leaked objects.
	17	+
	18	+ Most files don't exhibit leaks, but all files that have outlines
	19	+ do. I don't know whether it's because of circular object
	20	+ references.
	21	+
	22	+ General debugging: put a break point on 'stop_here()' and run qpdf
	23	+ --check memory-leak.pdf in gdb. For simplicity, configure with
	24	+ --disabled-shared CFLAGS=-g CXXFLAGS=-g. This will cause gdb to
	25	+ stop at the point of allocation of all the objects that are leaked.
	26	+ I'm still not sure which of these is the one that valgrind is
	27	+ complaining about, and I'm not really even sure that they're
	28	+ legitimate, though it's hard to imagine that they aren't.
	29	+
	30	+
	31	+Next
	32	+====
	33	+
	34	+ * Work in contrib/vc6. See email from stronghorse@tom.com
	35	+
1	36	2.2
2	37	===
3	38
...	...