[geos-devel] Request for Eyeballs
Paul Ramsey
pramsey at cleverelephant.ca
Thu Jul 23 20:22:44 PDT 2020
I'm trying to clean up memory use in the new overlayng code, on the overlay-sr branch, and have come to an impasse.
The valgrind report is here: https://gist.github.com/pramsey/d4be398473ea49ff4e241f5e7d4b855b
As I see it, there's one big set of NodedSegmenentString that are created by EdgeNodingBuilder and represent the un-noded input edges and stored in the member variable "inputEdges":
https://github.com/libgeos/geos/blob/overlay-sr/src/operation/overlayng/EdgeNodingBuilder.cpp#L78-L79
And those are cleaned up here:
https://github.com/libgeos/geos/blob/overlay-sr/include/geos/operation/overlayng/EdgeNodingBuilder.h#L203-L208
There's a second transient set of NodedSegmentString that are generated by the Noder, and come into existence here:
https://github.com/libgeos/geos/blob/overlay-sr/src/operation/overlayng/EdgeNodingBuilder.cpp#L98
And then disappear almost immediately afterwards here:
https://github.com/libgeos/geos/blob/overlay-sr/src/operation/overlayng/EdgeNodingBuilder.cpp#L103-L105
The valgrind report seems to implicate this second lifecycle in a huge leak and yet, it seems really self-contained. The MCIndexNoder generates some new NodedSegmentString, the ValidatingNoder just holds onto the list for a while, then passes it on to the EdgeNodingBuilder that uses them to generate some Edges, then deletes them.
The latest iteration of the branch is here. https://github.com/libgeos/geos/tree/overlay-sr/
Any and all feedbackk most appreciated,
P
More information about the geos-devel
mailing list