More Weird Behavior from the Draft WB: Memory Leak?

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
User avatar
yorik
Site Admin
Posts: 11574
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: More Weird Behavior from the Draft WB: Memory Leak?

Postby yorik » Wed Feb 14, 2018 12:31 pm

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
Posts: 8786
Joined: Mon Dec 12, 2011 4:45 pm

Re: More Weird Behavior from the Draft WB: Memory Leak?

Postby triplus » Wed Feb 14, 2018 2:00 pm

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
Posts: 50
Joined: Sun May 14, 2017 10:21 pm

Re: More Weird Behavior from the Draft WB: Memory Leak?

Postby cflin » Wed Feb 14, 2018 3:28 pm

yorik wrote:
Wed Feb 14, 2018 12:31 pm
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
Posts: 50
Joined: Sun May 14, 2017 10:21 pm

Re: More Weird Behavior from the Draft WB: Memory Leak?

Postby cflin » Tue Feb 20, 2018 12:52 am

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
Site Admin
Posts: 14988
Joined: Thu Feb 19, 2009 10:32 am

Re: More Weird Behavior from the Draft WB: Memory Leak?

Postby wmayer » Tue Feb 20, 2018 12:11 pm

According to top (Ubuntu) or task manager (Windows) the snapping still leaks some memory but it's much less than before.
User avatar
saso
Posts: 1336
Joined: Fri May 16, 2014 1:14 pm
Contact:

Re: More Weird Behavior from the Draft WB: Memory Leak?

Postby saso » Tue Feb 20, 2018 12:20 pm

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
Posts: 8786
Joined: Mon Dec 12, 2011 4:45 pm

Re: More Weird Behavior from the Draft WB: Memory Leak?

Postby triplus » Tue Feb 20, 2018 5:15 pm

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
User avatar
yorik
Site Admin
Posts: 11574
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: More Weird Behavior from the Draft WB: Memory Leak?

Postby yorik » Tue Feb 20, 2018 8:15 pm

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.
User avatar
saso
Posts: 1336
Joined: Fri May 16, 2014 1:14 pm
Contact:

Re: More Weird Behavior from the Draft WB: Memory Leak?

Postby saso » Tue Feb 20, 2018 9:41 pm

yorik wrote:
Tue Feb 20, 2018 8:15 pm
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.
User avatar
yorik
Site Admin
Posts: 11574
Joined: Tue Feb 17, 2009 9:16 pm
Location: São Paulo, Brazil
Contact:

Re: More Weird Behavior from the Draft WB: Memory Leak?

Postby yorik » Wed Feb 21, 2018 4:05 pm

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?