Ticket #4224 - hard crash with App::Link

Have some feature requests, feedback, cool stuff to share, or want to know where FreeCAD is going? This is the place.
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
User avatar
Zolko
Veteran
Posts: 2213
Joined: Mon Dec 17, 2018 10:02 am

Ticket #4224 - hard crash with App::Link

Post by Zolko »

Hello,

I have a hard crash in FreeCAD when doing some fancy linking and assembling. The idea is to implement a Top-Down approach in design, by having a master part (mcp stands for Master Control Part) that drives the assembly and all other parts. Therefore, this master control part is imported (linked) into the assembly, ans also in all parts that need the info that is in the MCP. The information is transferred from the MCP to the assembly and the parts by datum objects: to a datum in MCP is created a datum of the same type, and the Placement of this latter is set equal to that of the latter by ExpressionENgine. This works very well, no issue here. Finally, the part is imported (linked) into the assembly twice.

The assembly is structured in the following way:

Code: Select all

mcp_topdown (App::Part)
  │
  ├─ LCS_0
  ├─ Sketch_YZ
  ├─ Sketch_XZ
  ├─ Sketch_XY
  ├─ Point_1
  ├─ Point_2
  └─ LCS_1

part_topdown (App::Part, it's an Assembly4 Model)
  │
  ├─ LCS_0
  │
  ├─ MasterPart (App::Link to mcp_topdown)
  │    ├─ LCS_0
  │    ├─ ...
  │    ├─ Point_1
  │    ├─ Point_2
  │    └─ LCS_1
  │
  ├─ Point_1 (PartDesign::Point, with Placement set by EE to Point_1 in MasterPart)
  ├─ Point_2 (PartDesign::Point, with Placement set by EE to Point_2 in MasterPart)
  ├─ LCS_1 (PartDesign::CoordinateSystem, with Placement set by EE to LCS_1 in MasterPart)
  ├─ Sketch_1 (attached to LCS_1)
  └─ Extrude (Part::Extrude of Sketch_1)

asm_topdown (App::Part, it's an Assembly4 Model)
  │
  ├─ LCS_0
  │
  ├─ MasterPart (App::Link to mcp_topdown)
  │    ├─ LCS_0
  │    ├─ ...
  │    └─ LCS_1
  │  
  ├─ Part_1 (App::Link to part_topdown)
  │    ├─ LCS_0
  │    ├─ MasterPart (App::Link to mcp_topdown)
  │    │    ├─ LCS_0
  │    │    ├─ ...
  │    │    └─ LCS_1
  │    ├─ ...
  │    ├─ Sketch_1
  │    └─ Extrude
  │  
  ├─ Part_2 (App::Link to part_topdown)
  │    ├─ LCS_0
  │    ├─ MasterPart (App::Link to mcp_topdown)
  │    │    ├─ LCS_0
  │    │    ├─ ...
  │    │    └─ LCS_1
  │    ├─ ...
  │    ├─ Sketch_1
  │    └─ Extrude
  │  
As you can see, the MasterPart is linked several times, at various hierarchical levels. The idea is to have a single control thing that manages the entire assembly, in such a way that each part doesn't need to know the other parts, or the entire assembly, it's enough to have the Master Control Part, which is common to all parts. Thus, it is theoretically possible to split the work among several designers to make a complex assembly in parallel team-work. The merit of the idea goes to ppemawm:

ppemawm wrote: Sun Dec 01, 2019 5:47 pm So, I continued to explore top-down-design or in-context modelling with Assembly4 this week and tried something different ...
...
Assembly4 is proving to be an excellent vehicle for top-down-design or in-context modelling...
This, actually, works surprisingly well ... except that FreeCAD has trouble in dealing with it: if you open first the mcp_..., then the part_..., and then the assembly_..., and modify the parameters in the MasterPart, and update the part and assembly, every-thing works as expected, parts update, the sun shines and life is beautiful. But if you try to edit a Sketch from the MasterPart while in the assembly document, it hard-crashes FreeCAD, producing various interresting core-dumps:

Code: Select all

freecad: ../src/compiler/glsl_types.cpp:1002: static const glsl_type* glsl_type::get_array_instance(const glsl_type*, unsigned int, unsigned int): Assertion `((glsl_type *) entry->data)->fields.array == base' failed.
/tmp/.mount_FreeCA3FJ8Ex/AppRun: line 19: 29207 Aborted                 (core dumped) ${HERE}/usr/bin/freecad "$@"

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
#0  /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7eff6b918f20]
#1  0x7eff6e2b88a4 in Gui::DAG::Model::slotInEdit(Gui::ViewProviderDocumentObject const&) from /tmp/.mount_FreeCAABtXVj/usr/bin/../lib/libFreeCADGui.so+0x44
#2  /tmp/.mount_FreeCAABtXVj/usr/bin/../lib/libFreeCADGui.so(+0x369b3c) [0x7eff6e06fb3c]
#3  0x7eff6e0c8e64 in Gui::Document::setEdit(Gui::ViewProvider*, int, char const*) from /tmp/.mount_FreeCAABtXVj/usr/bin/../lib/libFreeCADGui.so+0x7f4
#4  0x7eff6e283e3f in Gui::TreeWidget::onStartEditing() from /tmp/.mount_FreeCAABtXVj/usr/bin/../lib/libFreeCADGui.so+0x10f
#5  0x7eff6c0657b8 in QMetaObject::activate(QObject*, int, int, void**) from /tmp/.mount_FreeCAABtXVj/usr/bin/../lib/libQt5Core.so.5+0x780
#6  0x7eff6c87396e in QAction::triggered(bool) from /tmp/.mount_FreeCAABtXVj/usr/bin/../lib/libQt5Widgets.so.5+0x32

Also, if you open the assembly first (asm_topdown) then it doesn't find the MasterPart (mcp_topdown) linked into the part_topdown, so you have to manually open the file mcp_topdown and refresh the part_topdown, after which everything is fine again. You can change the MasterPart in it's document window (mcp_topdown) and the assembly and the parts are updated correctly. But if you try to edit a Sketch form the MasterPart directly in the assembly or in the part document: segfault.

Now, you might say I shouldn't do these sort of things, but if we don't stress-test App::Link we'll not find the bugs. Also, if this work-flow did work as expected, this could be a very compelling method for a classical top-down design in fairly large and complex assemblies distributed over a team of designers.

But there seems to be some background document handling which goes wrong.


OS: Ubuntu 18.04.3 LTS (KDE/plasma)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.18846 (Git) AppImage
Build type: Release
Branch: master
Hash: ceeb776fff25c679752571d5d8e6c4c8b1fd9008
Python version: 3.7.3
Qt version: 5.12.5
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/United Kingdom (en_GB)
Attachments
asm_topdown.FCStd
(7.59 KiB) Downloaded 40 times
mcp_topdown.FCStd
(11.83 KiB) Downloaded 57 times
part_topdown.FCStd
(11.28 KiB) Downloaded 39 times
Last edited by Kunda1 on Fri Dec 13, 2019 11:59 pm, edited 1 time in total.
Reason: Added ticket number to thread title
try the Assembly4 workbench for FreCAD — tutorials here and here
User avatar
Zolko
Veteran
Posts: 2213
Joined: Mon Dec 17, 2018 10:02 am

Re: hard crash with App::Link

Post by Zolko »

Out of curiosity, I tried the same assembly with FreeCAD-asm3, realthunder's LinkStage3 branch prior to the inclusion into v0.19-dev. The syntax of the ExpressionEngine was different, but apart from that it opens without problems (the ExpressionEngines needed to be adapted, I digged out v0.5.5 of Assembly4, which was the latest compatible with that syntax).

And here, surprise: it doesn't crash. Ever. I can open whichever file I want, modify a sketch in any part or link, it never crashes. The parts and the assembly don't always update as wished, but it never crashes.

Now, thinking of it, doing such deep linking and creating all sort of dependencies might be tough for the program (FreeCAD), but either it should work or it should forbid to do things that are possible but crash-prone.

One possibility would be to forbid to edit functions inside a linked part if another window/document is already opened on the same part. Or forbid all-together to edit a function inside a linked object if that object belongs to another document: if the object is in the same document (as the link) there should be no problem, editing the linked object edits the actual object (in the same document), but editing a linked object that is in another document should be forbidden. The user should activate the document corresponding to the linked object and edit the function there. And then come back to the original assembly — containing the link — and update/recompute the assembly.

This would at least prevent segfaults, which are the worst a program can do: better to limit the possibilities and explain how to handle the case, than allow everything and let the program crash.
try the Assembly4 workbench for FreCAD — tutorials here and here
User avatar
Zolko
Veteran
Posts: 2213
Joined: Mon Dec 17, 2018 10:02 am

Re: hard crash with App::Link

Post by Zolko »

I tried to nail the problem down to the lowest level, and it's really a bug in how App::Link handles documents in the background. I've made the same assembly structure but using exclusively App::Part and App::Link functions, no Assembly4 whatsoever involved. The structure is the following:

  • Part_1 containing a Part::Cone
  • Part_2 containing a Part::Cylinder, and an App::Link to Part_1
  • asm containing an App::Link to Part_1 and another App::Link to Part_2 (which already has a link to Part_1 !)
The 3 files are attached for testing. The problem arises only when opening the top-level assembly first, when opening the parts starting from the lower level to up (Part_1 → Part_2 → asm) then everything works as expected, it's possible to edit Part_1 directly from asm document.

bug_linknotrestored.png
bug_linknotrestored.png (225.65 KiB) Viewed 1877 times

When opening the file asm.FCStdt, the result is actually 2 things, but which come from the same problem I think :

1) Link not restored: as you can see, the link to Part_1 is correctly restored in the file/document asm, but not in Part_2.

2) Segmentation fault: if you try to edit the Part::Cone of the — unrestored — Part_1, FreeCAD crashes:

Code: Select all

Program received signal SIGSEGV, Segmentation fault.
#0  /lib/x86_64-linux-gnu/libc.so.6(+0x3ef20) [0x7f258117ff20]
#1  /tmp/.mount_FreeCAPpt4OD/usr/bin/../lib/libFreeCADGui.so(+0x5b3193) [0x7f2583b20193]
...
EDIT: sorry, forgot:

OS: Ubuntu 18.04.3 LTS (KDE/plasma)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.18846 (Git) AppImage
Build type: Release
Branch: master
Hash: ceeb776fff25c679752571d5d8e6c4c8b1fd9008
Python version: 3.7.3
Qt version: 5.12.5
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/United Kingdom (en_GB)
Attachments
Part_2.FCStd
(7.5 KiB) Downloaded 36 times
Part_1.FCStd
(8.72 KiB) Downloaded 54 times
asm.FCStd
(6.18 KiB) Downloaded 38 times
try the Assembly4 workbench for FreCAD — tutorials here and here
User avatar
Zolko
Veteran
Posts: 2213
Joined: Mon Dec 17, 2018 10:02 am

Re: hard crash with App::Link

Post by Zolko »

I created a ticket #0004224 in the tracker:

https://www.freecadweb.org/tracker/view.php?id=4224
try the Assembly4 workbench for FreCAD — tutorials here and here
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Ticket #4224 - hard crash with App::Link

Post by realthunder »

PR submitted here. Note that the crash stack trace you posted in the issue page indicates that it happened in DAG view, because of lack of support of external objects there. I previously disabled this view, but wmayer re-enabled it for some reason. I'll see if I can get a quick fix for this. Meanwhile, to avoid crash when editing external object, please turn off boolean parameters in both Preferences/DAGView/Enabled, and Preferences/DockWindows/DAGView/Enabled.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
Zolko
Veteran
Posts: 2213
Joined: Mon Dec 17, 2018 10:02 am

Re: Ticket #4224 - hard crash with App::Link

Post by Zolko »

realthunder wrote: Sat Dec 14, 2019 6:00 am Meanwhile, to avoid crash when editing external object, please turn off boolean parameters in both Preferences/DAGView/Enabled, and Preferences/DockWindows/DAGView/Enabled.
yes, this avoids the crash to happen, but the "Link not restored" error remains.

Code: Select all

6.62e-07 <App> Document.cpp(2549): Assembly#Link.LinkedObject: Link not restored
Linked object: Part
Linked file: Part_1.FCStd
I played around with this problem, and it arises only when :

  • an object (App::Part) is included several times in an assembly....
  • ... at different hierarchical levels (in the top-level assembly, in a sub-assembly) ...
  • ... and it's first linked at the top-level assembly, and then the sub-assembly (where the object is linked) is linked into the top-level assembly
So exactly the assembly structure described above. I checked with FreeCAD-asm3-10.2 and it happens there too (note that it's not the same line # in Document.cpp)

Code: Select all

7.41e-07 <App> Document.cpp(2548): Assembly#Link.LinkedObject: Link not restored
Linked object: Part
Linked file: Part_1.FCStd

Code: Select all

Document.cpp:
                if(link && (res=link->checkRestore(&errMsg))) {
                    d->touchedObjs.insert(obj);
                    if(res==1)
                        FC_WARN(obj->getFullName() << '.' << prop->getName() << ": " << errMsg);
                    else  {
#2549 →                 FC_ERR(obj->getFullName() << '.' << prop->getName() << ": " << errMsg);
                        d->addRecomputeLog(errMsg,obj);
                        setStatus(Document::PartialRestore, true);
                    }
try the Assembly4 workbench for FreCAD — tutorials here and here
realthunder
Veteran
Posts: 2190
Joined: Tue Jan 03, 2017 10:55 am

Re: Ticket #4224 - hard crash with App::Link

Post by realthunder »

Zolko wrote: Sat Dec 14, 2019 11:30 am yes, this avoids the crash to happen, but the "Link not restored" error remains.
The link restore problem is fixed in this PR, more specifically, this commit.
Try Assembly3 with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
Zolko
Veteran
Posts: 2213
Joined: Mon Dec 17, 2018 10:02 am

Re: Ticket #4224 - hard crash with App::Link

Post by Zolko »

realthunder wrote: Sat Dec 14, 2019 1:40 pm The link restore problem is fixed in this PR, more specifically, this commit.
Thank-you, now I'll eagerly await the next AppImage. It's Christmas time !
try the Assembly4 workbench for FreCAD — tutorials here and here
User avatar
Zolko
Veteran
Posts: 2213
Joined: Mon Dec 17, 2018 10:02 am

Re: Ticket #4224 - hard crash with App::Link

Post by Zolko »

realthunder wrote: Sat Dec 14, 2019 6:00 am Note that the crash stack trace you posted in the issue page indicates that it happened in DAG view, because of lack of support of external objects there. I previously disabled this view, but wmayer re-enabled it for some reason. I'll see if I can get a quick fix for this.
I tried the DAG view before, but I must admit that:

1) I didn't find it helpful

2) the representation of the dependencies was so confusing that it didn't actually make any sense: the wires crossed each-other in such ways that it was impossible to easily follow what depended on what (which is the primary reason for this if I understood correctly). While I understand that such feature would be a good-to-have, especially for complex assemblies, the current implementation is useless.

3) I think that App::Link itself could be used in much better way to do exactly what the DAG view wanted to do. I'll write about it in another thread, but the short idea would be to have a sequential tree view, where all functions follow each other in the sequence of their creation, but each time a function depends on a previous one this previous function is linked as parent in the tree view. Today, when an extrusion is built on a sketch, the sketch disappears from the tree and is moved as child (or parent) of the extrusion: thus, it is impossible to know at what step the sketch was created. By leaving it where it is, but still linking it to the extrusion, one would get the information of the sequential build-up of the model, and also the co-dependencies of functions. Going a step further, if the sketch was mapped onto a datum plane, a link to the datum plane should appear underneath the sketch. And if the datum plane was built as a parallel plane passing by a point, both the reference plane and the point should appear underneath the plane.

EDIT: we'll leave this for v0.20, shall-we ?
try the Assembly4 workbench for FreCAD — tutorials here and here
vocx
Veteran
Posts: 5197
Joined: Thu Oct 18, 2018 9:18 pm

Re: Ticket #4224 - hard crash with App::Link

Post by vocx »

Zolko wrote: Sat Dec 14, 2019 7:41 pm ...
2) the representation of the dependencies was so confusing that it didn't actually make any sense: ...
I think the DAG view takes a while to get used to, but I assume it is implemented correctly. So, more than changing it radically, it requires more documentation to explain to the user what the lines mean. As I understand it, it is similar to how a Git repository with all its branches can be displayed.

After all, it's just an additional tool. FreeCAD has the tree view, DAG view, dependency graph, scene inspector, etc. They all have a purpose in explaining the relationships between the objects in the model.
...to have a sequential tree view, where all functions follow each other in the sequence of their creation, ...
I think this has been discussed in the past; basically, it is the basic operation of the tree view if objects weren't "absorbed" by others. However, after you create many objects, it quickly becomes a long and sequential historical list, and no longer a "tree".

It could make sense to create another view, while keeping the current tree view. The issue with what you say, is that many objects can be used by other features in parallel. So, having them in a sequential fashion is a bit restrictive. A single Sketch or solid can be used by different operations.
Always add the important information to your posts if you need help. Also see Tutorials and Video tutorials.
To support the documentation effort, and code development, your donation is appreciated: liberapay.com/FreeCAD.
Post Reply