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
│
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)