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 | Next | 1 | Next |
| 32 | ==== | 2 | ==== |
| 33 | 3 |