[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