More Weird Behavior from the Draft WB: Memory Leak?

[yorik]

Yes I also think there is something else... I'm trying to reduce the code until there is no memory raise at all, but that's really difficult to assess...

[triplus]

How about:

Code: Select all

import Part
edge = Part.LineSegment(FreeCAD.Vector(0,0,0),FreeCAD.Vector(2,2,2)).toShape()

for i in range(100000):
    edges = edge.Edges
    for e in edges:
        isinstance(e.Curve, (Part.LineSegment, Part.Line))

[cflin]

Yes I also think there is something else... I'm trying to reduce the code until there is no memory raise at all, but that's really difficult to assess...

From brief experiments on my end, I have found out that the GB-size memory leak happens when I try to use snapping on a particular object (part of a multi-part assembly) which causes FreeCAD to "think" a lot. Unfortunately, I don't think I can post the file with that object in public because it may be proprietary. If I remove that part from the multi-part tree, I cannot detect a memory leak (but then FC snaps instantaneously and does not have to "think" to find snap points). I just use 'top' and look at its output for the memory consumption of each process as a % of the total memory.

I can probably send you the file with the offending object in private.

[cflin]

It seems that with the latest FC update (see below), the memory leak is gone. Draft snapping on the same objects that caused the memory footprint to expand by several GB causes no perceptible (as far as 'top' is concerned) increase in the memory footprint. Also, FC snaps instantly (vs. "thinking" intensely before) on the same objects. I did not run more extensive tests on FC17, but I am inclined to think that the problem has been fixed. Here are the particulars of my newestFC17 installation:

OS: Ubuntu 16.04.3 LTS
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.13303 (Git)
Build type: None
Branch: master
Hash: b47e011c1cc6357fa776624d371ed434989c79b1
Python version: 2.7.12
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.1.0
Locale: English/UnitedStates (en_US)

[wmayer]

According to top (Ubuntu) or task manager (Windows) the snapping still leaks some memory but it's much less than before.

[saso]

Don't know if it has to do anything with this but there are a few issues reported in the Draft and DraftSnap python code from Coverity. For example:

CID 168946
Should it be in this line maybe "dim2" ?
https://github.com/FreeCAD/FreeCAD/blob ... ap.py#L917

CID 168964
Should it be in this line maybe "extLine2" ?
https://github.com/FreeCAD/FreeCAD/blob ... ap.py#L205

[triplus]

No difference on my side. Creating a Draft Rectangle and after circling around the edge of it with Draft Dimension will consistently increase the memory consumption.

Any opinion on this?

https://forum.freecadweb.org/viewtopic. ... 65#p214985

[yorik]

Saso's errors are now fixed in git commit f445ace40.

As for the rest, I added a few stronger tests that restrict the places where the memory leaks likely happen (which also speed things up a bit), but the problem is still not solved. But it might be that it doesn't happen anymore for you, depending on your snap settings.

[saso]

Saso's errors are now fixed in git commit f445ace40.

Great, there are 63 more like this (related to python code) in the report, if someone finds some time... Don't want to nag but it is probably good to check it from time to time.

[yorik]

I was able to narrow down the memory leak further, it seems to happen inside pivy. For example, this creates a ~30Mb memory increase (takes a couple of minutes to complete):

Code: Select all

from pivy import coin
c = coin.SoCoordinate3()
pts = [[0.0,0.0,0.0],[1.0,1.0,1.0]]
for i in range(1000000):
    c.point.setValues(pts)

When using Draft tools, and therefore snapping, there is a temporary line that is redrawn on every mouse move. There were more coin nodes unnecessarily redrawn too, which is now fixed in git commit 35ee3f03a. But there is of course no way to avoid changing the coordinates if we want to show that temporary line. But the memory leak has been reduced a lot. I must now stay several minutes hovering to get a couple Mb increase.

If extension or parallel snaps or snap dims are active, there are more temporary coin nodes being redrawn, and the memory consumption raises faster. Maybe these should be turned off by default...

Can someone else can test the code snippet above and confirm the memory being eaten?