Commit 7559934b023cd21d17b8f6ea3263282384a9a88f
1 parent
bf75e208
solved memory leak
git-svn-id: svn+q:///qpdf/trunk@973 71b93d88-0707-0410-a8cf-f5a4172ac649
Showing
1 changed file
with
0 additions
and
30 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 | 1 | Next |
| 32 | 2 | ==== |
| 33 | 3 | ... | ... |