[ Bug ] Recursive calling of recompute when moving a ShapeString (Linux only?)

[Roy_043]

I am doing some testing on Ubuntu and have occasional issues related to "Recursive calling of recompute". When moving a ShapeString the issue is reproducible:

1. Create a Draft_ShapeString at 0,0,0.
2. Move the object with Draft_Move: base point = 0,0,0; 2nd point = 0,10,0. I have snapped to the grid for those points.
3. Result: the object is now at 0,20,0 and has therefore moved twice.
4. There is also a warning: "1.518e-06 <App> Document.cpp(3458): Recursive calling of recompute for document ss".

The issue occurs on both versions listed below.

Code: Select all

OS: Ubuntu 22.04.1 LTS (ubuntu:GNOME/ubuntu)
Word size of FreeCAD: 64-bit
Version: 0.21.0.31488 (Git)
Build type: Release
Branch: master
Hash: 3e58513c24e533326906be5c87c82aafe582c936
Python 3.10.8, Qt 5.15.4, Coin 4.0.0, Vtk 9.1.0, OCC 7.6.3
Locale: English/United States (en_US)

Code: Select all

OS: Ubuntu Core 20 (ubuntu:GNOME/ubuntu)
Word size of FreeCAD: 64-bit
Version: 0.20.2.29177 +426 (Git) Snap 517
Build type: Release
Branch: tag: 0.20.2
Hash: 930dd9a76203a3260b1e6256c70c1c3cad8c5cb8
Python 3.8.10, Qt 5.15.5, Coin 4.0.0, Vtk 7.1.1, OCC 7.6.3
Locale: English/United States (en_US)

[chrisb]

I cannot reproduce on macOS. I haven't used the grid though (it's too much hassle to switch it on for just one action).

Code: Select all

OS: macOS 10.16
Word size of FreeCAD: 64-bit
Version: 0.21.0.31513 (Git)
Build type: Release
Branch: master
Hash: b2ab8edba4bfd71681e639f8c3f1105066bed4c7
Python 3.10.8, Qt 5.15.4, Coin 4.0.0, Vtk 9.1.0, OCC 7.6.3
Locale: C/Default (C)
Installed mods: 
  * FC_SU
  * DynamicData 2.46.0
  * freecad.gears 1.0.0
  * FeedsAndSpeeds 0.4.0
  * fcgear 1.0.0
  * fasteners 0.4.16
  * sheetmetal 0.2.60
  * ExplodedAssembly
  * Curves 0.6.1

[yorik]

I can't reproduce this either, but there have been some similar problems in the past due to containers like App::Part or BuildingParts. Is your shapestring inside one?

[wmayer]

I can confirm it

Code: Select all

OS: Ubuntu 22.04.1 LTS (XFCE/xubuntu)
Word size of FreeCAD: 64-bit
Version: 0.21.0.31567 (Git)
Build type: debug
Branch: master
Hash: 5b1c781b8ddb3c38a8c6121c9aafd590610a0578
Python 3.10.6, Qt 5.15.3, Coin 4.0.0, Vtk 7.1.1, OCC 7.5.1
Locale: German/Germany (de_DE)

[wmayer]

@chrisb @yorik
Please check your parameter settings for the key User parameter:BaseApp/Preferences/Document/CanAbortRecompute
Is its value is set to False for you?

The problem is the following:

• When moving the shape then after the click a timer is running that when triggered performs a recompute
• If the key CanAbortRecompute is true or doesn't exist (default is true) then a SequencerLauncher is created and calling its next() method processes pending events
• Processing the events triggers the timer a second time which then applies the movement twice and performs the recursive recompute

To fix the issue the Move command should be restructured to deregister the callback function before computing the changes.

But also the possibility to abort a recompute of the document should be removed. A call to process pending events on such a low-level part can cause very strange side-effects because it makes the execution order of functions unpredictable.

[chrisb]

@chrisb @yorik
Please check your parameter settings for the key User parameter:BaseApp/Preferences/Document/CanAbortRecompute
Is its value is set to False for you?

It is set to false here.

I retried with a plain vanilla config: works still flawless.
Checking the parameter: there is no parameter at all in BaseApp/Preferences/Document. After creating it and setting to true: still the same correct behaviour.
Changing the parameter to false - now I see a lot of other parameters too -: still the same correct behaviour.
It works correctly independently of moving with the mouse, with or without grid snapping or using the task panel.

[wmayer]

It works correctly independently of moving with the mouse, with or without grid snapping or using the task panel.

OK, thanks for testing. That it still works for you could be pure luck or the behaviour is system-dependent where in your case there is no pending event in the queue.

[Roy_043]

CanAbortRecompute

Setting this to False solves the issue on Ubuntu.

On my Windows system it was already set to False (I don't know why or how). Changing it to True on Windows also causes a recursive calling of recompute with the scenario from the OP, but not a double move operation.

deregister the callback function before computing the changes

Can you explain which callback this is and how this should be approached? Thanks.

[wmayer]

Can you explain which callback this is and how this should be approached? Thanks.

I only had a quick look at the code and haven't tested anything. But in gui_move.py you will find the class Move that registers gui_tool_utils.selectObject with view.addEventCallback.

Now when clicking the second time one of the methods of the Move class triggers the recompute and here it must be checked whether this happens before or after the call of view.removeEventCallback.

[Roy_043]

The mentioned callback is not involved as we are using a preselection.

AFAICT the actual callback is removed in the finish function, before the commit (which triggers execute and the recompute):
https://github.com/FreeCAD/FreeCAD/blob ... ve.py#L105
https://github.com/FreeCAD/FreeCAD/blob ... al.py#L157

Note that the problem does not occur if you Draft_Move a Part_Box or a Draft_Circle.

I suspect the problem may be partly due to the fact that when a ShapeString is moved its Shape gets updated inside the execute function, which somehow triggers execute again. But if you change the Placement of the ShapeString directly execute is not triggered twice.

In my solution for issue #8044 I try to avoid the creation of a new shape when possible. Maybe that issue and the problem discussed in this topic are related?